You should be able to run my fork on Linux.
I really didn't add anything Windows-specific this time around.
Topic: SILENTARMY v5: Zcash miner, 115 sol/s on R9 Nano, 70 sol/s on GTX 1070 - page 5. (Read 209334 times)
December 13, 2016, 10:29:54 PM
December 13, 2016, 10:04:10 PM
your fork will be Windows-only, correct?
i hope not at least i'm not gonna donate anything for windows only software
Marc (alias mrb) is working on the linux SA v6 miner separately, so there will be an OSS linux miner update. Also, zawawa's will be OSS, so anyone can port it to linux, if they want.
December 13, 2016, 09:41:56 PM
your fork will be Windows-only, correct?
i hope not at least i'm not gonna donate anything for windows only software
December 13, 2016, 09:34:46 PM
Although it is not as fast as Claymore's yet, it should be much faster than SA v5 on AMD cards.
how much fast?
I already sold most of my NVIDIA cards, so I have no idea how it would compare on NVIDIA cards.
If I had received a lot of donations, I could have justified purchasing GTX 1060 to my wife, but I could only dream...
If I had received a lot of donations, I could have justified purchasing GTX 1060 to my wife, but I could only dream...
will donate $50 for your GTX1060 fund
December 13, 2016, 09:24:42 PM
I will, I will. No worries. I will release my fork in a day or two.
Although it is not as fast as Claymore's yet, it should be much faster than SA v5 on AMD cards.
I already sold most of my NVIDIA cards, so I have no idea how it would compare on NVIDIA cards.
If I had received a lot of donations, I could have justified purchasing GTX 1060 to my wife, but I could only dream...
Thanks for your work! Just to clarify (for myself), your fork will be Windows-only, correct? I'm sure looking forward to looking at both your new code and Marc's, when they become available. It will be very interesting to see what approaches you each took on the algo/implementation. Don't let it interfere with your Holiday with the family, though! That's much higher priority! Best wishes ... Although it is not as fast as Claymore's yet, it should be much faster than SA v5 on AMD cards.
I already sold most of my NVIDIA cards, so I have no idea how it would compare on NVIDIA cards.
If I had received a lot of donations, I could have justified purchasing GTX 1060 to my wife, but I could only dream...
December 13, 2016, 07:56:53 PM
I will, I will. No worries. I will release my fork in a day or two.
Although it is not as fast as Claymore's yet, it should be much faster than SA v5 on AMD cards.
I already sold most of my NVIDIA cards, so I have no idea how it would compare on NVIDIA cards.
If I had received a lot of donations, I could have justified purchasing GTX 1060 to my wife, but I could only dream...
Although it is not as fast as Claymore's yet, it should be much faster than SA v5 on AMD cards.
I already sold most of my NVIDIA cards, so I have no idea how it would compare on NVIDIA cards.
If I had received a lot of donations, I could have justified purchasing GTX 1060 to my wife, but I could only dream...
December 13, 2016, 08:06:00 AM
I'm now using NR_ROWS_LOG=16 as the new sorting algorithm I implemented seems to prefer a larger NR_SLOTS.
I'm trying to set up NR_ROWS_LOG=14 and 15 to see how that would affect performance.
I'm trying to set up NR_ROWS_LOG=14 and 15 to see how that would affect performance.
I think 14 will be close to ideal. I expect 256 for NR_SLOTS will be enough to avoid row overflows, and that still allow using 1 byte for the row counters. That's 16KB * 2 for the row counters, or only 32KB.
I agree. This is a perfect reason to use a GCN assembler and squeeze two sets of 32KB rowCounters[] into 64KB GDS.
It is almost meant to be
Make it so
December 13, 2016, 07:54:10 AM
I'm now using NR_ROWS_LOG=16 as the new sorting algorithm I implemented seems to prefer a larger NR_SLOTS.
I'm trying to set up NR_ROWS_LOG=14 and 15 to see how that would affect performance.
I'm trying to set up NR_ROWS_LOG=14 and 15 to see how that would affect performance.
I think 14 will be close to ideal. I expect 256 for NR_SLOTS will be enough to avoid row overflows, and that still allow using 1 byte for the row counters. That's 16KB * 2 for the row counters, or only 32KB.
I agree. This is a perfect reason to use a GCN assembler and squeeze two sets of 32KB rowCounters[] into 64KB GDS.
It is almost meant to be
December 13, 2016, 07:49:52 AM
Did anybody implement NR_ROWS less than 16 support already ?
I was wondering about the same thing...
I'm almost done, but it's a major PITA to code.
December 13, 2016, 05:08:04 AM
Did anybody implement NR_ROWS less than 16 support already ?
Nope not yet..and welcome back :-D
December 13, 2016, 05:04:48 AM
Did anybody implement NR_ROWS less than 16 support already ?
December 12, 2016, 10:03:07 PM
I'm now using NR_ROWS_LOG=16 as the new sorting algorithm I implemented seems to prefer a larger NR_SLOTS.
I'm trying to set up NR_ROWS_LOG=14 and 15 to see how that would affect performance.
I'm trying to set up NR_ROWS_LOG=14 and 15 to see how that would affect performance.
I think 14 will be close to ideal. I expect 256 for NR_SLOTS will be enough to avoid row overflows, and that still allow using 1 byte for the row counters. That's 16KB * 2 for the row counters, or only 32KB.
Perfection takes time. :-) If you want to see the results of some of my research into memory performance, check this out:
https://github.com/nerdralph/cl-mem
December 12, 2016, 04:25:42 PM
Quote
I do not think the developers has much incentive to beat the Claymore. They are not rewarded properly.
why not implement 1% dev fee?
the linux miners are more stable
i don't have any stability problems with claymore's, and its not a linux miner.
December 12, 2016, 04:05:52 PM
Quote
I do not think the developers has much incentive to beat the Claymore. They are not rewarded properly.
why not implement 1% dev fee?
the linux miners are more stable
December 12, 2016, 03:26:35 PM
I'm now using NR_ROWS_LOG=16 as the new sorting algorithm I implemented seems to prefer a larger NR_SLOTS.
I'm trying to set up NR_ROWS_LOG=14 and 15 to see how that would affect performance.
I'm trying to set up NR_ROWS_LOG=14 and 15 to see how that would affect performance.
I think 14 will be close to ideal. I expect 256 for NR_SLOTS will be enough to avoid row overflows, and that still allow using 1 byte for the row counters. That's 16KB * 2 for the row counters, or only 32KB.
I got a feeling that this miner will beat up claymores
I do not think the developers has much incentive to beat the Claymore. They are not rewarded properly.
December 12, 2016, 02:43:36 PM
I'm now using NR_ROWS_LOG=16 as the new sorting algorithm I implemented seems to prefer a larger NR_SLOTS.
I'm trying to set up NR_ROWS_LOG=14 and 15 to see how that would affect performance.
I'm trying to set up NR_ROWS_LOG=14 and 15 to see how that would affect performance.
I think 14 will be close to ideal. I expect 256 for NR_SLOTS will be enough to avoid row overflows, and that still allow using 1 byte for the row counters. That's 16KB * 2 for the row counters, or only 32KB.
December 12, 2016, 02:32:50 PM
I'm now using NR_ROWS_LOG=16 as the new sorting algorithm I implemented seems to prefer a larger NR_SLOTS.
I'm trying to set up NR_ROWS_LOG=14 and 15 to see how that would affect performance.
I'm trying to set up NR_ROWS_LOG=14 and 15 to see how that would affect performance.
I think 14 will be close to ideal. I expect 256 for NR_SLOTS will be enough to avoid row overflows, and that still allow using 1 byte for the row counters. That's 16KB * 2 for the row counters, or only 32KB.
I got a feeling that this miner will beat up claymores
December 12, 2016, 02:02:23 PM
I'm now using NR_ROWS_LOG=16 as the new sorting algorithm I implemented seems to prefer a larger NR_SLOTS.
I'm trying to set up NR_ROWS_LOG=14 and 15 to see how that would affect performance.
I'm trying to set up NR_ROWS_LOG=14 and 15 to see how that would affect performance.
I think 14 will be close to ideal. I expect 256 for NR_SLOTS will be enough to avoid row overflows, and that still allow using 1 byte for the row counters. That's 16KB * 2 for the row counters, or only 32KB.
December 12, 2016, 12:38:11 PM
By the way, I found out the root cause of a low number of shares.
It turned out that there is a bug in AMD's drivers, so you need to so specify the "-O1" build option to disable most of optimizations when you call clBuildProgram if the miner is running on AMD cards. The optimizer must have incorrectly eliminated s_waitcnt. What a wonderful world.
How to fork this? Do you have a method?It turned out that there is a bug in AMD's drivers, so you need to so specify the "-O1" build option to disable most of optimizations when you call clBuildProgram if the miner is running on AMD cards. The optimizer must have incorrectly eliminated s_waitcnt. What a wonderful world.
If you want to share with us?
December 12, 2016, 10:00:17 AM
By the way, I found out the root cause of a low number of shares.
It turned out that there is a bug in AMD's drivers, so you need to so specify the "-O1" build option to disable most of optimizations when you call clBuildProgram if the miner is running on AMD cards. The optimizer must have incorrectly eliminated s_waitcnt. What a wonderful world.
It turned out that there is a bug in AMD's drivers, so you need to so specify the "-O1" build option to disable most of optimizations when you call clBuildProgram if the miner is running on AMD cards. The optimizer must have incorrectly eliminated s_waitcnt. What a wonderful world.
is your fork ready for release? thanks
Jump to: