Guidance on next steps to undervolt MSI Gaming X 570 via ohgodatool, hex

midwestEmidwestE Member Posts: 9
I've been working to decrease the wattage via core undervoltage on ethos for the 9 x MSI Gaming X 570 4G cards. Love these cards so, very good cooling under load (58c). Been doing research and testing for the last few weeks into how I can decrease the watt draw. I know I can switch to windows and get the desired effect, but call me stubborn mule, I just don't like windows xD.

Currently, the 9 cards are pulling about 1370w while dual mining. Averages out to about 152w a card gross, net it comes to about 133w a card (core 42w + 9 x 14w per riser = 168w) at powertune state 2.

Here's the avenues I've tried in my attempt to decreasing the watt draw:

1) Edit the mv in core states in PBE and set the voltage directly instead of using the pointers - This doesn't seem to work as the AMD driver seems to ignore directly set core mv.

2) Recompiling the kernal amd driver per https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/amd-linux/918649-underclocking-undervolting-the-rx-470-with-amdgpu-pro-success - I really just dont like this method because it involves hard coding the voltage in a compiled format and being a web developer this kinda goes against "the code"

3) Using ohgodatool to change the voltage offset:
ohgodatool -i $CARD --core-state 2 --core-vddc-off -27

DPM state 2:
VDDC: 65283 (voltage table entry 2)
VDDC offset: -27
Core clock: 1125

It's a bit strange, i shut down the miner issue the command to change the VDDC offset, restart the miner and the rig then takes near 1800w after changing the offset by 1

4) Use ohgodatool to change the core state voltage table index:
ohgodatool -i $CARD --core-state 2 --core-vddc-idx 11

Voltage state 11:
VDD = 950
CACLow = 0
CACMid = 0
CACHigh = 0

DPM state 2:
VDDC: 65283 (voltage table entry 10)
VDDC offset: -26
Core clock: 1125
Same thing happens here as with the voltage offset change above, miner runs at 1800w

5) Use ohgodatool to table set the existing voltage state (2)
ohgodatool -i $CARD --volt-state 2 --vddc-table-set 950
Same thing happens here as with the voltage offset change above, miner runs at 1800w

6) Edit the VBIOS in a hex editor and add an offset or adjust an offset. I followed along with the tutorial provided by Gup Sterg here:



but I'm seems this bios doesn't have a settable voltage offset. Ran into issues here as the object seems to be very short and I'm having issues identifying the structure of the table and the IC. Here's the excerpt
0020:   abea  Len 0034  Rev 03:01  (VoltageObjectInfo/VRAM_GPIO_DetectionInfo)

34 00 03 01 01 07 0C 00 0E 00 00 00 00 00 00 00 04 00 24 00 00 04 00 00 02 80 10 00 00 00 00 00 20 03 00 00 10 00 52 03 02 00 00 00 84 03 02 00 10 00 B6 03



Can anyone point me to some next step resources that would help me make some progress on either decreasing core voltage using ohgodatool or via hex edit. Feel like I been spinning my wheels and could use to be pointed in the right direction. Thanks!

Comments

  • Wolf0Wolf0 Member Posts: 322 ✭✭✭
    Neither of the mods with OhGodATool will work for you - OhGodATool is quite simple; it allows you to modify the fields of the PowerPlayInfo table (some of these are editable in PBE & SRBPolaris, but not all.) What it does *not* do, is guarantee the VBIOS PowerPlayInfo table's settings are honored - at all - and honestly, there's some settings in there that straight up cannot be modifed on all the Polaris (Ellesmere) cards I've found... and I attempt to always buy different models/brands to have a good mix. An example of this is MVDDC - you ain't changing this shit without a hardmod.

    Now, about how you can get it to actually lower the voltage being fed to core... I recently did an educational (free) edit for someone to demonstrate the technique - you can see it in detail starting here: https://forum.ethereum.org/discussion/comment/82600/#Comment_82600

    As for the specifics of yours? I'm not gonna parse that hex via eye, even though I technically could. Post the VBIOS itself for people to look! :P
  • midwestEmidwestE Member Posts: 9
    Thanks for the direction Wolf. I'll have to put some work in on that thread before I'll be able to ask some semi-intelligent questions. Seems like one of the first things I need to do is understand and be able to identify whats what in that voltage object (size, format revision, content revision, type, mode, size, etc)

    msi_gamingx_570_stock.tar.gz | msi_gamingx_570_stock.zip
  • Wolf0Wolf0 Member Posts: 322 ✭✭✭
    midwestE said:

    Thanks for the direction Wolf. I'll have to put some work in on that thread before I'll be able to ask some semi-intelligent questions. Seems like one of the first things I need to do is understand and be able to identify whats what in that voltage object (size, format revision, content revision, type, mode, size, etc)

    msi_gamingx_570_stock.tar.gz | msi_gamingx_570_stock.zip

    Your chances on doing it with this one I honestly would put at quite slim, sadly. It has no section for initializing the regulator, which means if we only look at the VoltageObjectInfo table, we can't even ID the controller yet. While I do believe it is technically possible to do so in the VBIOS via inserting and entire voltage object into the VBIOS' VoltageObjectInfo table (similar to how one would insert extra I2C codes into an existing voltage object for initializing the regulator) - my attempts haven't been successful. That's not to discourage you from trying if you wanna give it a shot - I'll be honest: at that point, wolfamdvolt had just finished rounding out support for most common functions one would want to do with a VRM controller, and once I added Hawaii support, and the one new controller I found out of my collection of those, I ended up saying, "fuck it - I can already control the damn thing better at runtime than I can through a VBIOS flash; not worth the hassle."
  • midwestEmidwestE Member Posts: 9
    Thanks for looking into it. Inserting the whole object is a bit above my mastery at the moment, but in considering it my first thought in trying to insert an entire object is to find a MSI Gaming 580 bios, maybe 570 armor and see if it looks at all similar and go from there. Probably a fool hearty idea but hey it's free to think :)

    Imagine it took a helluva lot of time and brain cycles to code out wolfamdvolt and I don't see it out there, so imagine you're keepin in close to the vest.

    Suppose if I'm looking at either going to windows or trying to recompile the drm driver w hard coded voltage and replace the existing .ko driver in ethos, that's what I may have to work toward before I have to bite the windows bullet



  • Wolf0Wolf0 Member Posts: 322 ✭✭✭
    It's actually named ohgodavolt, now, fitting in with the other tool names - but yeah, it is.

    Sorry about that one - kernel mod might be your best go at it if you want to avoid the Windows hell.
  • midwestEmidwestE Member Posts: 9
    edited August 21
    Thanks again for taking the time to respond. I do appreciate the advice.

    When you worked at inserting a whole voltage object, did you do it completely "by paw" or did you start with something close or similar and mod it from that starting point?

    If i attempted to co-opt a similar object table (if one even exists), is the likelihood high, medium or low in bricking the card when i make the inevitable mistake? I've had to recover a few cards from bad flashes and had success but in all cases they were at least recognized.

    Even in failure, I'll learn a little something in the process, just don't want the lesson to be too painful!
  • Wolf0Wolf0 Member Posts: 322 ✭✭✭
    midwestE said:

    Thanks again for taking the time to respond. I do appreciate the advice.

    When you worked at inserting a whole voltage object, did you do it completely "by paw" or did you start with something close or similar and mod it from that starting point?

    If i attempted to co-opt a similar object table (if one even exists), is the likelihood high, medium or low in bricking the card when i make the inevitable mistake? I've had to recover a few cards from bad flashes and had success but in all cases they were at least recognized.

    Well... pretty much everything new. Not hard to create, cause all you need is the header info... I2C address is in 7-bit format, so shift left by 1 bit to convert it from (what I would consider) the conventional one. Only one you probably won't know is the Regulator ID. This one stumped me on my MSI Gaming X RX580 8G... because while I know it's got a uP9505P by visual inspection (and tbh, you could get it from having a chat with it over I2C, as well), I have not seen a regulator init section for this particular controller - if it has an ID assigned, I don't know it. This could have been my issue - not sure.

    I could perhaps try on some of my XFX ones - they don't have an init regulator section, but they have an NCP81022, which I shouldn't have any problem crafting a totally legit voltage object for of type init regulator...
  • midwestEmidwestE Member Posts: 9
    I can definitely test but as you can tell, I wouldn't be too much help until I learned quite a bit more. If it's something you can do in a short order and are interested to put another feather in your cap, be all means.

    If it starts to be more than just a small task, please let me know. Time is valuable and I'd like to give you something for yours considering you already have another way around it.

    Early work tomorrow, so signing of for tonight. Thanks again
  • midwestEmidwestE Member Posts: 9
    Actually Wolf, was reading on some custom ram timings on bitcointalk and saw you are swamped already with plenty of work to do. Going to try to do the kernel smumgr today after work and make progress there. If I can't get it done, I'll pay you your rate and get in line. Thanks again!
  • midwestEmidwestE Member Posts: 9
    @Wolf0 Found that the ethos amdgpu driver source isnt available as it seems to be using fglrx. For giggles, tried to replace the amd amdgpu.ko with one built from another version of ubuntu 14, of course, didnt work.

    Soooo, been trying to spin up my own ubuntu build with the amdgpu pro drivers from amd:

    Tried Ubuntu 16.04.3 LTS server, desktop, Lubuntu server, desktop with the 17.30 drivers and also older 16.30 drivers. Both with kernel 4.4 and 4.10 and each one upon boot after installing the drivers gives me errors when initiating powerplay.



    Did plenty of research but all the reference seems to indicate it should work just fine with 16.04.3 out the box. Any help on versions (kernel and amd driver) that are known to work together?
  • Wolf0Wolf0 Member Posts: 322 ✭✭✭
    It seems to be working, just possibly having some issues. Could also be the firmware needs updating.
  • midwestEmidwestE Member Posts: 9
    you were right, seems that the firmware had something to do with the errors. i temporarily moved the amdgpu firmware folder out of /lib/firmware/4.10... and updated initramfs and the errors seem to be gone, ty!!

    identified the firmware was copied there by there latest version of the amd driver install. going to look to see if i can find even later firmware out there.

    using a combination of some echos and ohgodatool a was able to setup a sysctrl script that sets the clocks and power tune on startup.

    however, it seems that something is fucked up with the way the driver handles the vbios settings. I'm testing on two 470 armor 8g cards with basic strap modifications. it has a tdp and max power of about 85w. when i take readings from the killawatt by removing a card, it's showing 140w being used per card. does the amd driver ignore the tdp and max power completely???
  • Wolf0Wolf0 Member Posts: 322 ✭✭✭
    Nope, but usage from the ASIC alone does not equal usage of the entire GPU PCB.
Sign In or Register to comment.