why not using vector store...damn it, I few more weeks and I'll get in rails with OpenCL.
vector store address must be aligned by 16 bytes, it is not possible in any round because of different offsets
Topic: SILENTARMY v5: Zcash miner, 115 sol/s on R9 Nano, 70 sol/s on GTX 1070 - page 27. (Read 209309 times)
November 20, 2016, 04:41:16 PM
vector store address must be aligned by 16 bytes, it is not possible in any round because of different offsets
November 20, 2016, 04:28:08 PM
Quote
Well... erm... dunno how to say this, but not only is vdrop+.rom not edited in Heliox's style, it doesn't seem to be edited for voltage AT ALL - even in the ways that DON'T work. All the DPM states on vdrop+.rom point stock (into the voltage table, which has not been changed). The core clocks have been dropped pretty much across the board, though. Default memory clock was changed to 2080, but the rest of the memory states are untouched.
Heliox/Eliovp would (in a low-power ROM) have added a new VID for the initialization of the regulator in VoltageObjectInfo (changing the length of the table), as well as a value for it, which allows for global core undervolts that apply to every power state.
https://forum.ethereum.org/discussion/9650/sapphire-rx-480-nitro-oc-8gb-11260-01-20g-modded-bios-29-mh-downvoltHeliox/Eliovp would (in a low-power ROM) have added a new VID for the initialization of the regulator in VoltageObjectInfo (changing the length of the table), as well as a value for it, which allows for global core undervolts that apply to every power state.
Here is where I got these bioses. I haven't touched vbios for 8 years...last time I modded vbios was when I got Radeon 9800Pro for PC and flashed it with Mac rom to put it in my G4
So basicly my knowledge of this is pretty much narrowed to minimum. Don't judge me too harsh... I just started mining (1/2 weeks ago)
Yeah, silentarmy does NOT take kindly to copied straps, I noticed. I had to re-do half of my 380's strap to get any improvements at all. This is likely because of the writes used - Eth you write once (more or less) and read frequently, just different pieces. Doing a read after a write incurs a delay, for example, so you have to be more creative.
( reffering myself)It's not really stupidity, I spent a long ass time learning more than I EVER, EVER wanted to know about GDDR5 SDRAM.
Hell, you could do even better - just tcpdump all the traffic for a few days, pull out any addressed that aren't yours and have a proxy (something like iptables) rewrite it such that the devfee address is changed to your own. I think there's a really simple tool for this, too - called netsed - but I didn't look really deeply into it.
November 20, 2016, 04:27:36 PM
I have been tweaking disassembled GCN codes of SA's kernels, and there seems to be quite a bit of room for performance enhancements, especially by optimizing global memory access by reordering flat_store_dword and s_waitcnt in ht_store(). @eXtremal, how are your next batch of optimizations coming along? If they are almost ready, I will wait for them. Otherwise, I will optimize the OpenCL kernel myself and then tweak the GCN code.
xor_and_store and ht_store must be rewrited, and joined to one function.
unaligned 32 bits reads in xor_and_store -> join in 64bit in half_aligned_long -> 64bit xor in xor_and_store -> on 2,4,6,8 round 256bit shift on xi0xi1xi2xi3 in xor_and_store -> 256bit shift again in ht_store -> split in 32bit, and write in ht_store
must be rewrited to:
unaligned 32 bits reads - > 32 bit xor -> 256bit shift -> 32 or 64 bit, or vector store
or
64 bits reads -> 64 bit xor -> 64 bit 256bit shift -> 64bit or vector store
or
64 and 32 bit reads -> 64 and 32 bit xor -> mixed 256bit shift -> 64bit or 32bit or vector store
depend on round
November 20, 2016, 04:21:08 PM
Quote
Well... erm... dunno how to say this, but not only is vdrop+.rom not edited in Heliox's style, it doesn't seem to be edited for voltage AT ALL - even in the ways that DON'T work. All the DPM states on vdrop+.rom point stock (into the voltage table, which has not been changed). The core clocks have been dropped pretty much across the board, though. Default memory clock was changed to 2080, but the rest of the memory states are untouched.
Heliox/Eliovp would (in a low-power ROM) have added a new VID for the initialization of the regulator in VoltageObjectInfo (changing the length of the table), as well as a value for it, which allows for global core undervolts that apply to every power state.
https://forum.ethereum.org/discussion/9650/sapphire-rx-480-nitro-oc-8gb-11260-01-20g-modded-bios-29-mh-downvoltHeliox/Eliovp would (in a low-power ROM) have added a new VID for the initialization of the regulator in VoltageObjectInfo (changing the length of the table), as well as a value for it, which allows for global core undervolts that apply to every power state.
Here is where I got these bioses. I haven't touched vbios for 8 years...last time I modded vbios was when I got Radeon 9800Pro for PC and flashed it with Mac rom to put it in my G4
So basicly my knowledge of this is pretty much narrowed to minimum. Don't judge me too harsh... I just started mining (1/2 weeks ago)
Yeah, silentarmy does NOT take kindly to copied straps, I noticed. I had to re-do half of my 380's strap to get any improvements at all. This is likely because of the writes used - Eth you write once (more or less) and read frequently, just different pieces. Doing a read after a write incurs a delay, for example, so you have to be more creative.
( reffering myself)It's not really stupidity, I spent a long ass time learning more than I EVER, EVER wanted to know about GDDR5 SDRAM.
November 20, 2016, 04:01:02 PM
Quote
Well... erm... dunno how to say this, but not only is vdrop+.rom not edited in Heliox's style, it doesn't seem to be edited for voltage AT ALL - even in the ways that DON'T work. All the DPM states on vdrop+.rom point stock (into the voltage table, which has not been changed). The core clocks have been dropped pretty much across the board, though. Default memory clock was changed to 2080, but the rest of the memory states are untouched.
Heliox/Eliovp would (in a low-power ROM) have added a new VID for the initialization of the regulator in VoltageObjectInfo (changing the length of the table), as well as a value for it, which allows for global core undervolts that apply to every power state.
https://forum.ethereum.org/discussion/9650/sapphire-rx-480-nitro-oc-8gb-11260-01-20g-modded-bios-29-mh-downvoltHeliox/Eliovp would (in a low-power ROM) have added a new VID for the initialization of the regulator in VoltageObjectInfo (changing the length of the table), as well as a value for it, which allows for global core undervolts that apply to every power state.
Here is where I got these bioses. I haven't touched vbios for 8 years...last time I modded vbios was when I got Radeon 9800Pro for PC and flashed it with Mac rom to put it in my G4
So basicly my knowledge of this is pretty much narrowed to minimum. Don't judge me too harsh... I just started mining (1/2 weeks ago)
Yeah, silentarmy does NOT take kindly to copied straps, I noticed. I had to re-do half of my 380's strap to get any improvements at all. This is likely because of the writes used - Eth you write once (more or less) and read frequently, just different pieces. Doing a read after a write incurs a delay, for example, so you have to be more creative.
( reffering myself) November 20, 2016, 03:45:30 PM
Quote
Well... erm... dunno how to say this, but not only is vdrop+.rom not edited in Heliox's style, it doesn't seem to be edited for voltage AT ALL - even in the ways that DON'T work. All the DPM states on vdrop+.rom point stock (into the voltage table, which has not been changed). The core clocks have been dropped pretty much across the board, though. Default memory clock was changed to 2080, but the rest of the memory states are untouched.
Heliox/Eliovp would (in a low-power ROM) have added a new VID for the initialization of the regulator in VoltageObjectInfo (changing the length of the table), as well as a value for it, which allows for global core undervolts that apply to every power state.
https://forum.ethereum.org/discussion/9650/sapphire-rx-480-nitro-oc-8gb-11260-01-20g-modded-bios-29-mh-downvoltHeliox/Eliovp would (in a low-power ROM) have added a new VID for the initialization of the regulator in VoltageObjectInfo (changing the length of the table), as well as a value for it, which allows for global core undervolts that apply to every power state.
Here is where I got these bioses. I haven't touched vbios for 8 years...last time I modded vbios was when I got Radeon 9800Pro for PC and flashed it with Mac rom to put it in my G4
So basicly my knowledge of this is pretty much narrowed to minimum. Don't judge me too harsh... I just started mining (1/2 weeks ago)
November 20, 2016, 03:44:26 PM
I have been tweaking disassembled GCN codes of SA's kernels, and there seems to be quite a bit of room for performance enhancements, especially by optimizing global memory access by reordering flat_store_dword and s_waitcnt in ht_store(). @eXtremal, how are your next batch of optimizations coming along? If they are almost ready, I will wait for them. Otherwise, I will optimize the OpenCL kernel myself and then tweak the GCN code.
November 20, 2016, 02:07:58 PM
Quote
Well... erm... dunno how to say this, but not only is vdrop+.rom not edited in Heliox's style, it doesn't seem to be edited for voltage AT ALL - even in the ways that DON'T work. All the DPM states on vdrop+.rom point stock (into the voltage table, which has not been changed). The core clocks have been dropped pretty much across the board, though. Default memory clock was changed to 2080, but the rest of the memory states are untouched.
Heliox/Eliovp would (in a low-power ROM) have added a new VID for the initialization of the regulator in VoltageObjectInfo (changing the length of the table), as well as a value for it, which allows for global core undervolts that apply to every power state.
https://forum.ethereum.org/discussion/9650/sapphire-rx-480-nitro-oc-8gb-11260-01-20g-modded-bios-29-mh-downvoltHeliox/Eliovp would (in a low-power ROM) have added a new VID for the initialization of the regulator in VoltageObjectInfo (changing the length of the table), as well as a value for it, which allows for global core undervolts that apply to every power state.
Here is where I got these bioses. I haven't touched vbios for 8 years...last time I modded vbios was when I got Radeon 9800Pro for PC and flashed it with Mac rom to put it in my G4
So basicly my knowledge of this is pretty much narrowed to minimum. Don't judge me too harsh... I just started mining (1/2 weeks ago)
November 20, 2016, 12:53:08 PM
ZEC, like ETH, wants you to max out the memory clock as much as you can on a 1070 to maximise hashrate - even if you have to drop the core clock some to keep the card stable.
NVidia support for OpenCL is very much a grudging afterthought - they really want you do use CUDA 'cause they OWN CUDA.
NVidia support for OpenCL is very much a grudging afterthought - they really want you do use CUDA 'cause they OWN CUDA.
that is strange then because i get more hash when i underclock my 1070 than overclocking, overclocking has benefit only with very high oc like +700 mem at least
November 20, 2016, 12:43:39 PM
Hey, which command can be used to reduce % to GPU ?
There is no such option right now. November 20, 2016, 10:42:09 AM
Hey, which command can be used to reduce % to GPU ?
November 19, 2016, 07:42:21 PM
ZEC, like ETH, wants you to max out the memory clock as much as you can on a 1070 to maximise hashrate - even if you have to drop the core clock some to keep the card stable.
NVidia support for OpenCL is very much a grudging afterthought - they really want you do use CUDA 'cause they OWN CUDA.
NVidia support for OpenCL is very much a grudging afterthought - they really want you do use CUDA 'cause they OWN CUDA.
November 19, 2016, 05:15:22 AM
zawawa, on a 1070 what would be the optimal thing to do under clock or over clock the gpu?
how much more do you think we can get out of the 1070's
how much more do you think we can get out of the 1070's
I don't own a 1070, so I cannot give you a definite answer. If my experience with 980 Ti is applicable, I would bump up the memory clock. I am pretty sure other people have better answers, though.
As for the second question, I would venture to guess that there is some room for performance improvements. Generally speaking, NVIDIA's OpenCL implementations suck balls, so CUDA ports should be much faster than the original OpenCL program, unless you take advantage of dynamic, run-time compilation of the kernel, which is only possible with OpenCL. We will see.
November 19, 2016, 02:46:26 AM
Right now, I'm focusing on making cards hash more on memory-using algos across the board with VBIOS mods.
If you have any timings for Hynix BFR ICs that are similar in performance to The Stilt's Hynix AFR and Elpida BBBG timings I'd love to test them out
I've not yet experimented with values enough to find out EXACTLY how they interact for best performance.
Oh well it was worth a shot.
I guess it is a very time-consuming thing to figure out. Stilt said himself it took 50 hours to do the timing set for one card. November 19, 2016, 12:55:28 AM
zawawa, on a 1070 what would be the optimal thing to do under clock or over clock the gpu?
how much more do you think we can get out of the 1070's
how much more do you think we can get out of the 1070's
November 18, 2016, 11:16:17 PM
Wolf, what is your private ZEC miner capable of ?
You're assuming I have one. Right now, I'm focusing on making cards hash more on memory-using algos across the board with VBIOS mods.
A quick question.
4 Identical RX 480 Sapphire OC 8GB. 2 of them handle well vdrop+ by ElioVP the other 2 make a lot of gpu faults... Any idea?
P.S. First 2 were clocked to 1236Mhz Core the other to 1306Mhz default.
Thanks in advance.
@zawawa
Any chance to gain access to your modifications?
I am sure I will release my code when eXtremal's new optimization comes out.
November 18, 2016, 07:48:41 PM
Scrypt GPU mining ended in the fall of 14 without private kernels. x11 started up shortly there after, became unprofitable at the beginning of winter. Gridseed weren't ASICs either, the first ones weren't very profitable or good. You may have just remembered those little USB things coming out and thought 'well those were ASICs', they weren't. There were a lot of really bad ASICs. Gridseeds were never a good deal.
Unless you were running private kernels yourself, it wasn't happening.
What other algo are you looking at that's mature? Dagger doesn't count. That's a very niche scenario and it's bound almost exclusively by bus width. The GPUs never get a chance to even be close being fully utilized.
R9-290 has a 512bit bus as was already mentioned.
Who tests GPUs on sha-256? How about trying something remotely relevant to the discussion like say NeoS, Lyra2v2, or even x11. People haven't made optimized miners for Sha in years. As mentioned before if you're talking about 'theoretical usage' scenarios, video games are a very good example of that as GPUs are made to run as fast as possible on them.
Memory usage doesn't need to be about bandwidth or bus width, it could just be the total memory usage as well. Not just that, it doesn't need to be restricted JUST to throughput, it can utilize memory and still do a lot of processing on GPUs. At this point though you're just making shit up and theorycrafting again.
You can blame latency all you want, but Fury not only has a 4096 bit bus, but also gobs of memory bandwidth, it's not eight times faster then R9-290 or even twice as fast. It's not just all about memory speeds here or even latency.
The Gridseed 3355 WAS in fact an ASIC - and on scrypt it was more efficient than anything GPU based at the time by quite a bit. single side of an "80 blade" would pull 2.5 Mhash/sec at 40 watts where the best GPUs of the time were pulling less than half that at a LOT more power (7990 was an exception with it's pair of cores, it could actually manage a bit more than half the hashrate but pulled a TON more power to do so).
Dagger (ETH) isn't "bus width limited, it's memory access limited - NOT the same thing or the RX 480 wouldn't even be close to matching the R9 290 on hashrate.
For MOST usage, the Fury is a LOT faster than the R9 290 - but on ETH it's barely in the same ballpark despite the much higher "in theory" memory bandwidth. *SOMETHING* certainly keeps it uncompetative with much older cards with lower rated memory bandwidth.
ASIC in name, not in the ability to disrupt network difficulty. They were worthless when it came to a cost/performance ratio. Only thing they had was efficiency, but they hashed so little it didn't even matter.
Dagger is definitely limited by bus width with the exception of the outliers such as HBM and GDDR5-X. Cards are different, but you can sum up general performance by that. You're welcome to offer some of your amazing specs to dispute that if you wish.
(cores can't be compared across generations of cards or chip makers).
AMD cores in the GCN generations have been pretty consistant on their performance, if anything they've gotten a hair MORE efficient with generational changes.
Comparing GCN to Terrascale cores or to NVidia cores (which I've NOT DONE AT ALL, strawman comment there) is a lot more problematical.
AMD reused chips across multiple card generations, such as 2XX and 3XX. You can't compare compute cores between a Fury and a Hawaii or to different manufacturers like Nvidia. Most of the time the architecture changes with each new generation, but AMD did rebrands. I'm talking particularly about different generations of chips, not rebrands. if you want to read into that and argue rebrands go for it.
Let's talk about it, then. Most 290Xs (I've had three, and others report the same) clock to 1500 on the memory. 20% OC on the clock.
Most 480s can BARELY get to 2250 - which, over a stock clock of 2000, is only a 12.5% increase. Oh, yeah, and that's still on a smaller bus.
Most 480s can BARELY get to 2250 - which, over a stock clock of 2000, is only a 12.5% increase. Oh, yeah, and that's still on a smaller bus.
Yup. I didn't even hit on that one, but there definitely isn't more room on AMDs newer models. They made sure to tighten that up as much as possible
November 18, 2016, 06:55:06 PM
Right now, I'm focusing on making cards hash more on memory-using algos across the board with VBIOS mods.
If you have any timings for Hynix BFR ICs that are similar in performance to The Stilt's Hynix AFR and Elpida BBBG timings I'd love to test them out
November 18, 2016, 06:41:43 PM
Quote
Well... erm... dunno how to say this, but not only is vdrop+.rom not edited in Heliox's style, it doesn't seem to be edited for voltage AT ALL - even in the ways that DON'T work. All the DPM states on vdrop+.rom point stock (into the voltage table, which has not been changed). The core clocks have been dropped pretty much across the board, though. Default memory clock was changed to 2080, but the rest of the memory states are untouched.
Heliox/Eliovp would (in a low-power ROM) have added a new VID for the initialization of the regulator in VoltageObjectInfo (changing the length of the table), as well as a value for it, which allows for global core undervolts that apply to every power state.
https://forum.ethereum.org/discussion/9650/sapphire-rx-480-nitro-oc-8gb-11260-01-20g-modded-bios-29-mh-downvoltHeliox/Eliovp would (in a low-power ROM) have added a new VID for the initialization of the regulator in VoltageObjectInfo (changing the length of the table), as well as a value for it, which allows for global core undervolts that apply to every power state.
Here is where I got these bioses. I haven't touched vbios for 8 years...last time I modded vbios was when I got Radeon 9800Pro for PC and flashed it with Mac rom to put it in my G4
So basicly my knowledge of this is pretty much narrowed to minimum. Don't judge me too harsh... I just started mining (1/2 weeks ago)
Heh, don't worry about it, I won't. I'll just tell you what's there. Or not there. Looking it over now.
Thank you. PM your T address and I will put one VM core to mine on it 24/7.
Okay, so, the regulator initialization hasn't been touched, so there's no global core under/over volting going on - at least not that way. But... what is this? Unlike the other two ROMs you posted, this does undervolt the states... in a really bizarre fashion. Instead of updating the pointers in the DPM states into the voltage table to all point to DPM state 3... it has written DPM state 3's voltage value into the voltage table for entries 4, 5, 6, and 7. I can only guess at the cause of this oddity, but it might be something Polaris BIOS Editor does.
The 1625 strap has been copied up to 1750 and 2000 - I would HIGHLY advise against this for stability reasons on Samsung memory. Elpida and Hynix are happy even taking the 1500 strap all the way up to 2000, but Samsung hates it in my experience, and while it may look good at first, keeping the cards running will probably be hell.
The clocks in this VBIOS have been edited for most (if not all) of the DPM states - similar to your v4.rom and vdrop+.rom. Default memclock on it is 2080 for state 1 (performance) - the idle state is untouched.
The name of the VBIOS image file implies it was dumped from a Sapphire Nitro+, but it doesn't look like it to me. Sapphire Nitro+ cards (all 470s and 480s I've seen, regardless of mem type) have an offset in the voltage regulator init that does a (by default) overvolt of +25mV to core across all power states. This VBIOS does not. But it does go to a card with the same connectors - 2 DisplayPort and 2 HDMI Type A, and one DVI-D.
You don't need to donate, don't worry about it.
I would recommend copying the 1750 strap to 2000 for stability - you should also be able to clock higher. As for the voltage mods... honestly, not entirely sure they will take effect (at least not on both Windows and Linux), but if they drop wattage for you and are stable, then use 'em.
When my new 480s arrive I will play with one of them...just now I need them to mine for a while to be able to pay powerbill with this freefall of ZEC
Thank you for the time spent on my issues.
November 18, 2016, 06:35:40 PM
You don't need to donate, don't worry about it.
I really love this guy.
Most of the time he just puts some gems in front of our noses.
Jump to: