I can't get ethash-new to connect to any pools (Using windows).
Same, although it seemed to work on nicehash...
Topic: Gateless Gate Sharp 1.3.8: 30Mh/s (Ethash) on RX 480! - page 150. (Read 214410 times)
Same, although it seemed to work on nicehash...
I can't get ethash-new to connect to any pools (Using windows).
I just added ethash-new.cl to GG and got 26.5 Mh/s with stock RX 480 on Windows after I tweaked the settings a little bit.
I already updated the repository, and I will upload a new version either today or tomorrow.
I already updated the repository, and I will upload a new version either today or tomorrow.
I think you were being a bit lazy with the cut/paste though. GPU_SINGLE_ALLOC_PERCENT=100? We're not mining ETH with 2GB cards any more...
Intensity, worksize, and the number of threads. You can see sample configurations in .bat files in the repository.
An Eth miner at same speed at claymore would be really nice!, since we dont have anything good as him right now =/
SGMiner-GM is about as fast if you tune it, and with a new kernel, way better at low core clocks.
Great work indeed. I think an auto-tune feature would definitely help for people to see how fast your kernels are.
I actually didn't write ethash-new - dunno who did.
hmmm... I tried but never succeeded to run it properly... "ethash-new" kernel bundled with sgminer-5.5.5-gm-nicehash-8
I just added equihash-new.cl to GG and got 26.5 Mh/s with stock RX 480 on Windows after I tweaked the settings a little bit.
I already updated the repository, and I will upload a new version either today or tomorrow.
An Eth miner at same speed at claymore would be really nice!, since we dont have anything good as him right now =/
SGMiner-GM is about as fast if you tune it, and with a new kernel, way better at low core clocks.
Great work indeed. I think an auto-tune feature would definitely help for people to see how fast your kernels are.
I actually didn't write ethash-new - dunno who did.
hmmm... I tried but never succeeded to run it properly... "ethash-new" kernel bundled with sgminer-5.5.5-gm-nicehash-8
I just added ethash-new.cl to GG and got 26.5 Mh/s with stock RX 480 on Windows after I tweaked the settings a little bit.
I already updated the repository, and I will upload a new version either today or tomorrow.
An Eth miner at same speed at claymore would be really nice!, since we dont have anything good as him right now =/
SGMiner-GM is about as fast if you tune it, and with a new kernel, way better at low core clocks.
Great work indeed. I think an auto-tune feature would definitely help for people to see how fast your kernels are.
I actually didn't write ethash-new - dunno who did.
hmmm... I tried but never succeeded to run it properly... "ethash-new" kernel bundled with sgminer-5.5.5-gm-nicehash-8
An Eth miner at same speed at claymore would be really nice!, since we dont have anything good as him right now =/
SGMiner-GM is about as fast if you tune it, and with a new kernel, way better at low core clocks.
Great work indeed. I think an auto-tune feature would definitely help for people to see how fast your kernels are.
An Eth miner at same speed at claymore would be really nice!, since we dont have anything good as him right now =/
Have been following this thread for a few weeks. Most of this is above my head. I do understand that there are improvements being made. 2 really basic questions though...
1) Do these improvements only help equihash? or would they boost all algorithms? specifically interested in ethash/daggerhashimoto.
2) Are these improvements only available on linux or would they translate to windows as well?
1) Do these improvements only help equihash? or would they boost all algorithms? specifically interested in ethash/daggerhashimoto.
2) Are these improvements only available on linux or would they translate to windows as well?
1) Yes. I am particularly interested in dual-mining.
2) Eventually. I just need to figure out how to enable one crucial feature of the graphics card on Windows. Everything else is in place.
Have been following this thread for a few weeks. Most of this is above my head. I do understand that there are improvements being made. 2 really basic questions though...
1) Do these improvements only help equihash? or would they boost all algorithms? specifically interested in ethash/daggerhashimoto.
2) Are these improvements only available on linux or would they translate to windows as well?
1) Do these improvements only help equihash? or would they boost all algorithms? specifically interested in ethash/daggerhashimoto.
2) Are these improvements only available on linux or would they translate to windows as well?
And since everything but the nonce is constant for ~2.5 minutes, you can probably move some of the calculations to compile time and generate a new kernel for each new block. Since you're already building a custom llvm, you can probably get the kernel compile and dispatch time down to a few ms.
You don't need a compiler. You can inject the blake2s precalc into the instructions. Dual mine round0 with self modified code. Should be faster than Claymore and optiminer..
Excellent! I am revising the data structure of the hash table right now.
Let me get to that when I'm done.
And since everything but the nonce is constant for ~2.5 minutes, you can probably move some of the calculations to compile time and generate a new kernel for each new block. Since you're already building a custom llvm, you can probably get the kernel compile and dispatch time down to a few ms.
You don't need a compiler. You can inject the blake2s precalc into the instructions. Dual mine round0 with self modified code. Should be faster than Claymore and optiminer..
Another potential issue to consider is cache pollution by the background kernel as that could also severely degrade the performance of the foreground tasks. I wish I knew all this from the very beginning, but I suppose we all live and learn.
On nvidia its bether to move precalc tables into the instruction cache. Bether for dual mining/kernels.
I found that, for an efficient implementation of dual mining with the memory-bound foreground kernel and compute-intense background kernel, you really need to be careful with the number of wavefronts/warps and the timings of kernel launches. The whole point is to keep the foreground and background kernels together on the GPU as long as possible so that they can be switched back and forth without performance penalty, and that would be impossible if there are too many concurrent wavefronts and/or kernel executions are not synchronized properly. Another potential issue to consider is cache pollution by the background kernel as that could also severely degrade the performance of the foreground tasks. I wish I knew all this from the very beginning, but I suppose we all live and learn.
So... what you are saying is that it's not worth it or ? Because you said you gained 5% speed with it...
Oh, I think it's totally worth it. That number is with my naive initial implementation. I will give you an update shortly with a new number.
I found that, for an efficient implementation of dual mining with the memory-bound foreground kernel and compute-intense background kernel, you really need to be careful with the number of wavefronts/warps and the timings of kernel launches. The whole point is to keep the foreground and background kernels together on the GPU as long as possible so that they can be switched back and forth without performance penalty, and that would be impossible if there are too many concurrent wavefronts and/or kernel executions are not synchronized properly. Another potential issue to consider is cache pollution by the background kernel as that could also severely degrade the performance of the foreground tasks. I wish I knew all this from the very beginning, but I suppose we all live and learn.
So... what you are saying is that it's not worth it or ? Because you said you gained 5% speed with it...
I found that, for an efficient implementation of dual mining with the memory-bound foreground kernel and compute-intense background kernel, you really need to be careful with the number of wavefronts/warps and the timings of kernel launches. The whole point is to keep the foreground and background kernels together on the GPU as long as possible so that they can be switched back and forth without performance penalty, and that would be impossible if there are too many concurrent wavefronts and/or kernel executions are not synchronized properly. Another potential issue to consider is cache pollution by the background kernel as that could also severely degrade the performance of the foreground tasks. I wish I knew all this from the very beginning, but I suppose we all live and learn.
GG is finally running faster with the parallelized Round 0.
I fused Round 0 with Rounds 7 and 8 to alleviate cache contamination and to improve the cache hit ratio for the next Round 1. I could even merge it with the solution-searching kernel for better results.
Good stuff.
You also could try SLC writes to bypass the L2 cache.I fused Round 0 with Rounds 7 and 8 to alleviate cache contamination and to improve the cache hit ratio for the next Round 1. I could even merge it with the solution-searching kernel for better results.
Good stuff.
I tried various combinations of SLC/GLC bits, but they didn't work quite well.
I think I figured out how to implement dual mining properly, though. We will see in a bit...
GG is finally running faster with the parallelized Round 0.
I fused Round 0 with Rounds 7 and 8 to alleviate cache contamination and to improve the cache hit ratio for the next Round 1. I could even merge it with the solution-searching kernel for better results.
Good stuff.
You also could try SLC writes to bypass the L2 cache.I fused Round 0 with Rounds 7 and 8 to alleviate cache contamination and to improve the cache hit ratio for the next Round 1. I could even merge it with the solution-searching kernel for better results.
Good stuff.
GG is finally running faster with the parallelized Round 0.
I fused Round 0 with Rounds 7 and 8 to alleviate cache contamination and to improve the cache hit ratio for the next Round 1. I could even merge it with the solution-searching kernel for better results.
Good stuff.
I fused Round 0 with Rounds 7 and 8 to alleviate cache contamination and to improve the cache hit ratio for the next Round 1. I could even merge it with the solution-searching kernel for better results.
Good stuff.
So how much faster?
Around 5% increase in speed at this point.
I am thinking about dynamic compilation of the kernel to simplify the blake2b calculations as nerdralph suggested.
Probably Optiminer is doing this already anyway.
Jump to: