Very nice results with 290(X), any chance for 280x gain?
In order to do the same optimizations on 280(x), the code would need to be almost completely rewritten to work on 32 bit numbers instead of 64 (because of lds usage), hoping for the vgprs count (which is mostly in compiler control and very difficult to reduce by modifying the opencl code) to be low enough to permit 2 wavefronts. Or, maybe, a better compiler in the future could do it by itself. As of now, I think the best is using the asm version for 280(x) and my last binary for 290(x). Why do you think this, ASM version is driver independent and relies on directly coding for GPU, there is very little difference between 280x and 290, 290 has more shaders, true. Buts basic code optimize such as your first/last pass should work in ASM just as well or better considering that AMD lobotomized OCL compiler after 14.7 14.12 is the first version making Hawaii specific code which, in some cases, may bring sensible improvements. On Tahiti, the compiler simply can't make code capable of running 2 wavefronts. Or maybe it can but I'm not able to make it do it, on Hawaii I can instead. Hawaii is not just Tahiti with more shaders... |
|
|
|
Very nice results with 290(X), any chance for 280x gain?
In order to do the same optimizations on 280(x), the code would need to be almost completely rewritten to work on 32 bit numbers instead of 64 (because of lds usage), hoping for the vgprs count (which is mostly in compiler control and very difficult to reduce by modifying the opencl code) to be low enough to permit 2 wavefronts. Or, maybe, a better compiler in the future could do it by itself. As of now, I think the best is using the asm version for 280(x) and my last binary for 290(x). |
|
|
|
I suggest this be done now to protect invest of a lot of coins. U do not know the power of Anonymous  Reactor is indeed a good target as popshot pointed out with 70K+ and only 50K needed for doublespend attack. U Effin read me wrong, I am all for security of DMD but I will not risk my investment and time in something I do not feel is secure. BTW risc = reduced instruction set computer. Please learn english. Obtaining 50k is not that trivial. It's unlikely someone spent so many BTC to attack just for lolz (losing their own invested money in the process). Reactor is hidden well enough and finding out who holds keys or knows the IP address would be much hassle. As mentioned before, Diamond due to its mechanics is much better secured (naturally) than so many other pure fast staking PoS coins. I do not believe we are at the top of the hit list, even if such list exists. IP can be found if u have the knowledge, then it just a matter of gaining root access, and looking at configs to gain access to RPC commands to wallet ... trivial for the truly gifted. This is just a warning that it CAN be done you still need the private key |
|
|
|
Hi Pallas, The bin file is not working on both the sgminer 4.1.0 from Diamond website and sgminer 5 from Wolf0. After the ...kernel is experimental... display, both sgminer version either hanged or display black screen. Maybe the sgminer needs the specific v2 diamond.cl file to function properly. BTW, unlike v1, changing the name of your .bin file to match the one sgminer generated does not work either. the binary can work without the sources. check that you are running a 64 bit miner (the official diamond miner is 32 bit), that you are using worksize 128 and that you are setting the correct bin file name. and of course that you have a hawaii card! :-) |
|
|
|
new bin for hawaii in my thread
As always Pallas, excellent work! Is this based on realhet's work? What results do you get (can we expect)? it's my opencl kernel, further tweaked for speed and compatibility, with help from realhet as you can see by reading the thread. his asm version (completely different work) is still better for non-hawaii cards. from the OP: v2 - experimental hawaii only bin: R9 290x @1125 Mhz: ~34.4 Mh/s R9 290 @1100: ~30.6 Mh/s very fast.what's the power? I'm more interested in the temp.. that depends on your cards, cooling system, room temperature etc. |
|
|
|
new bin for hawaii in my thread
As always Pallas, excellent work! Is this based on realhet's work? What results do you get (can we expect)? it's my opencl kernel, further tweaked for speed and compatibility, with help from realhet as you can see by reading the thread. his asm version (completely different work) is still better for non-hawaii cards. from the OP: v2 - experimental hawaii only bin: R9 290x @1125 Mhz: ~34.4 Mh/s R9 290 @1100: ~30.6 Mh/s very fast.what's the power? slightly higher than with the old kernel |
|
|
|
new hawaii bin in my thread.
Pallas, I commend you for your efforts trying to squeeze more hashing power out of our existing hardware. However, I gave this new bin a try on my R9 290s and I am sorry to say I did not see any improvement over the optimizations UtahJohn posted last week. I can get as much as 28 mh/s out of some of my 290s but that's what I was getting before. Having said that, this is an improvement over your last release so again, thanks and keep this up. More hashing power from our existing investments in hardware helps us keep up with the increase difficulties. I just wish my power company would figure out a way to reduce my energy costs! I don;t understand how with oil prices down so much my cost per kilowatt hour is going up. It's about 2% faster than the asm version by hetpas and compiled for Tahiti by utahjohn. The reason I didn't release it before is I was hoping to tweak it further and get some more performance. Unfortunately I didn't and besides I lost interest because I stopped mining and, apart from utahjohn, nobody seemed interested in it. |
|
|
|
new bin for hawaii in my thread
As always Pallas, excellent work! Is this based on realhet's work? What results do you get (can we expect)? it's my opencl kernel, further tweaked for speed and compatibility, with help from realhet as you can see by reading the thread. his asm version (completely different work) is still better for non-hawaii cards. from the OP: v2 - experimental hawaii only bin: R9 290x @1125 Mhz: ~34.4 Mh/s R9 290 @1100: ~30.6 Mh/s |
|
|
|
|
new bin for hawaii in my thread
|
|
|
|
Thx pallas! But im out of the game cos i have 280s only. Utahjohn too (i think so).
the new kernel should make no difference on tahiti cards, but we will eventually make some tests later anyway: the reason is compatibility with newer drivers. |
|
|
|
yes the power usage is different, but the card always runs that hot, it's the fan speed that changes.
and when power consumption is very low, it means the algo is not well optimised ;-)
Well I'm not good in programming, but anyway Scrypt hashrate is 10 times slower than X11 on my GPU for example, but it runs hot. scrypt is one of the best optimized algos out there. that's why it runs hot. it hashes slower than x11 because tha algo is inherently slower. a single hash takes more instructions and, more importantly, memory accesses. when groestlcoin came out, its power consumption was very low. the kernel was so slow it is now 3x faster and power consumption has gone up to the same level as other algos, like keccak for example. |
|
|
|
it's not 'cause of the kernel, it runs that hot with all algos ;-)
That's strange... Maybe for AMD is ok, I don't know. But different algos on my GTX 770 warms different... For example scrypt burns card around 80C after 5 min mining, X11 around 70, Fresh, Quark etc around 65-67... yes the power usage is different, but the card always runs that hot, it's the fan speed that changes. and when power consumption is very low, it means the algo is not well optimised ;-) |
|
|
|
no worry, it's a reference design card, been running that hot for more than a year without problems.
Maybe it's not so critical but anyway it's psychological barier for me.. it's not 'cause of the kernel, it runs that hot with all algos ;-) |
|
|
|
|
new hawaii bin in my thread.
|
|
|
|
92C  I have butthurt when my GPU reach 80, but 92... no worry, it's a reference design card, been running that hot for more than a year without problems. |
|
|
|
This seems to be the best CPU GPU coin out there, keep it up  Not really CPU, more focused on GPU I think... I said CPU coin because there is no much advantage using GPU specially compared watts to watts or the GPU miner is not well optimized. Maybe watts for watts GPU is not efficient, but you can put several GPU in one PC. The total hash is higher. the algorythm has been designed to be memory heavy and thus gpu unfriendly; like cryptonight, for example. regardless, if you look at nicehash or yaamp, lyra2RE is never the most profitable algo to mine. because of this, and the fact that it's used by vertcoin only, who mines it must be a vertcoin believer. when that's the case, performance/watt is not that important. |
|
|
|
|
even easier for the people would be selling the hardware with preinstalled software, or selling a bootable sdcard to be put into the device.
also a web interface would be killer.
|
|
|
|
|
Show Posts
