@mike_do All right, I'm going to do this one for you free of charge for two reasons. One, it's on an open forum, so everyone (including you) can see the before/after and learn from it, and two, I've never actually done an undervolt on this specific VRM controller via the VBIOS before (the uP1637.) Stand by. You're gonna need to test it, possibly several times, until it's right.
@mike_do Waaaaait a minute... before I do this, can you get me an I2C dump of it? Something is fishy here - the VBIOS says that the offset 0x20 (7-bit address, so actually 0x40) - but... the regulator ID states that it is a uP1637... this combination is quite impossible. Just like my Sappire Pulse 580 8G, it is lying to me.
Before I put in I2C codes, I wanna make sure they're not going to an address with nobody home.
For those looking for instructions in the future -- download AIDA64, then go to View -> Status Bar (make sure it's checked). Then right-click the bottom left AIDA64 icon -> Video Debug -> ATI SMBus Dump. Viola.
FUCK, I'm retarded - I read 10 and thought it was decimal 10 - it was 0x10. This thing doesn't have a uP1637, it has an NCP81022. This means that the I2C address is 0x20, which is indeed possible for an NCP81022.
I haven't used this particular method on an NCP81022 before, but an interesting idea would be to tell the controller to no longer listen to commands over SVI2 at all, then set its VID. This would mean that the driver can no longer set voltage, though, so you'd lose power savings (especially when idle.) I do this when I undervolt in real-time on Linux using my toolset - I don't care if the driver can't use it now, because I use my tools to bring the voltage up and down as I please.
That's not the method I plan to take here, though - I'll just offset the output voltage. This way, the driver will happily send VIDs over SVI2, and the NCP81022 will obey, but it'll apply a negative offset to its main output (the one driving the ASIC.) Basically, if I set the offset to -25mV, and the driver sets the VID such that it should output 1025mV, the final result on the output rail will be 1000mV.
Almost forgot to fix the little Sapphire signature fuckup with their newer cards - the I2C address is supposed to be in 7-bit format, so I have to change it from 0x20 -> 0x40, or the I2C commands will go into the void. This VBIOS should apply a -75mV offset, which works on ALL OSes that support the GPU:
@Wolf0 Loaded up the VBIOS successfully. Ran it versus the stock VBIOS (upon which you based the mod) on 17.7.1 using ethminer's benchmarking mode (block 4100000). I did not do any tuning in any tool (like WattTool or MSI AB).
Both VBIOS' drew the same wall watts (156w). System is ~43w, so card is drawing ~113w.
Given both runs were the same I am guessing the instructions were ignored by the controller.
@Wolf0 Loaded up the VBIOS successfully. Ran it versus the stock VBIOS (upon which you based the mod) on 17.7.1 using ethminer's benchmarking mode (block 4100000). I did not do any tuning in any tool (like WattTool or MSI AB).
Both VBIOS' drew the same wall watts (156w). System is ~43w, so card is drawing ~113w.
Given both runs were the same I am guessing the instructions were ignored by the controller.
just to make sure I am not being stupid - this doesn't require me to do anything in software, correct? WattTool for example shows 1000mV for both core and memory. I am not changing any values there.
just to make sure I am not being stupid - this doesn't require me to do anything in software, correct? WattTool for example shows 1000mV for both core and memory. I am not changing any values there.
Did you reboot after flashing the ROM? And can you try it on Linux? I'm pretty sure I had it right the first time... lemme pull out a Sapphire 470 4G (later model, should be similar) and put it in Naomi.
Okay - did so, and turns out, Sapphire is just straight up lying about where the NCP81022 is at. It's not a 7-bit format to 8-bit format fuckup - just a fuckup. The NCP81022 on my test Sapphire is ACTUALLY at 0x25 (8-bit format), meaning the VOI entry should show the address as 0x4A (7-bit format.) When this is done, the offset works as normal. Your NCP81022 was *also* at 0x25, but I glanced over the actual address in too much of a hurry. Note to self: Pay more attention.
Unfortunately, I'll need to extend my I2C table once more, because I'm setting an offset on the wrong damn output!
I understand the impact this has (-75mV), but can you describe what is happening with this new segment?
When I only put 0xF4 into 0xE6, it offset the second loop (which, nothing is connected to it.) As such, I put 0x00 into 0xD2 to select the main loop, as well as reset most of the settings in that reg to a sane default value, before doing the offset.
For those following along at home, the attached image shows the diff between stock VBIOS and that which @wolf0 modded.
I see 4 changes:
1. Size of entire table was changed from 42 00 to 4A 00 to accommodate insertion (see #4 below) 2. Size of voltage object 1 was changed from 0E 00 to 16 00 for same reason 3. I2C address was changed from 20 to 4A, due to Sapphire being annoying 4. Between reserved bytes and terminate the following was added: D2 00 00 00 E6 00 F4 00
NOTE: screenshot is confusing, original is on the right, modded on the left.
For those following along at home, the attached image shows the diff between stock VBIOS and that which @wolf0 modded.
I see 4 changes:
1. Size of entire table was changed from 42 00 to 4A 00 to accommodate insertion (see #4 below) 2. Size of voltage object 1 was changed from 0E 00 to 16 00 for same reason 3. I2C address was changed from 20 to 4A, due to Sapphire being annoying 4. Between reserved bytes and terminate the following was added: D2 00 00 00 E6 00 F4 00
NOTE: screenshot is confusing, original is on the right, modded on the left.
Very good - but you missed a couple of things. The other tables following VOI had their offsets fixed to account for the new size of VOI, and I trimmed the padding between the legacy & UEFI VBIOSes to ensure the image remained the same size before correcting the checksum.
At least I'll have something to point folks to when they ask me about undervolting that takes effect on all OSs (AKA properly undervolting via VBIOS offset mods.)
At least I'll have something to point folks to when they ask me about undervolting that takes effect on all OSs (AKA properly undervolting via VBIOS offset mods.)
Very thank You for this, it cleared all the blur for me.
I remember when i modded my own BIOS (i had also NCP80122 VRM) and it worked for me only adding E6 00 XX 00 , D2 00 00 00 part wasn't necessary on my RX570 Nitro+, weird. I wish my uP9505 were so easy as NCP80122
Comments
I am around and available to test. And if we brick, well, shall be it.
Thanks!!!
Before I put in I2C codes, I wanna make sure they're not going to an address with nobody home.
Try this?
For those looking for instructions in the future -- download AIDA64, then go to View -> Status Bar (make sure it's checked). Then right-click the bottom left AIDA64 icon -> Video Debug -> ATI SMBus Dump. Viola.
This one is it!
------[ ATI I2C Device GPU #1 / B06-D25 ]------ 0000 FFFF 2980 7817 FF7F FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0010 6900 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 4AB0 FFFF FFFF FFFF FFFF FFFF FFFF 0020 6622 0000 FFFF FFFF 0000 0018 00A8 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0030 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0001 0000 FFFF FFFF FFFF FFFF FFFF FFFF 0040 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0064 FFFF FFFF FFFF FFFF 0055 0050 FFFF 0046 0000 0064 FFFF 0010 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0060 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 012C FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0070 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FD00 0000 2B00 4000 5600 3D00 FFFF FFFF 0080 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF D2EB FFFF FFFF 0154 9A30 0000 FFFF FFFF 0090 FFFF FFFF FFFF FFFF FFFF FFFF 9A5F FFFF FFFF 001A 1022 8703 FFFF FFFF FFFF FFFF 00A0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 00B0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 00C0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 00D0 E400 8801 3200 5003 BA0D 2A02 9900 FFFF FFFF FFFF 6401 FFFF FFFF FFFF FFFF FFFF 00E0 FFFF 6E00 D300 B602 A703 CC03 7800 0058 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 00F0 FFFF FFFF FFFF 0568 FFFF FFFF FFFF 9C0F F5BC F29C FFFF 4203 FFFF 1B0F FFFF FFFF
I haven't used this particular method on an NCP81022 before, but an interesting idea would be to tell the controller to no longer listen to commands over SVI2 at all, then set its VID. This would mean that the driver can no longer set voltage, though, so you'd lose power savings (especially when idle.) I do this when I undervolt in real-time on Linux using my toolset - I don't care if the driver can't use it now, because I use my tools to bring the voltage up and down as I please.
That's not the method I plan to take here, though - I'll just offset the output voltage. This way, the driver will happily send VIDs over SVI2, and the NCP81022 will obey, but it'll apply a negative offset to its main output (the one driving the ASIC.) Basically, if I set the offset to -25mV, and the driver sets the VID such that it should output 1025mV, the final result on the output rail will be 1000mV.
http://46.28.204.78/Sapphire-NCP81022-UV.rom
Both VBIOS' drew the same wall watts (156w). System is ~43w, so card is drawing ~113w.
Given both runs were the same I am guessing the instructions were ignored by the controller.
just to make sure I am not being stupid - this doesn't require me to do anything in software, correct? WattTool for example shows 1000mV for both core and memory. I am not changing any values there.
I will spin up linux on a drive I have laying around. Probably won't have an answer until tomorrow. Any objection to Ubuntu? I usually put 16.04.
Unfortunately, I'll need to extend my I2C table once more, because I'm setting an offset on the wrong damn output!
Annoyed at Sapphire for being difficult. Attention to detail! (Sapphire, not you!)
[[email protected] ~]# ./vrmprobe vrmprobe v0.1 GPU 0: Number of VRMs: 0 GPU 1: Number of VRMs: 1 VRM 0: NCP81022 Number of outputs: 2 Output 0: Voltage: 0.9500 Offset: -0.0750 Output 1: Voltage: 0.0000 Offset: 0.0000 [[email protected] ~]#
VBIOS is here:
Before modification for voltage: http://46.28.204.78/Sapphire-NCP81022-Stock.rom
After modification for voltage: http://46.28.204.78/Sapphire-NCP81022-UV.rom
I parsed the hex and noticed you added the following (between reserved bytes and terminate)
00 00 00 (reserved bytes)
D2
00 00 00
E6
00
F4
00
FF 00 (terminate)
I understand the impact this has (-75mV), but can you describe what is happening with this new segment?
I see 4 changes:
1. Size of entire table was changed from 42 00 to 4A 00 to accommodate insertion (see #4 below)
2. Size of voltage object 1 was changed from 0E 00 to 16 00 for same reason
3. I2C address was changed from 20 to 4A, due to Sapphire being annoying
4. Between reserved bytes and terminate the following was added: D2 00 00 00 E6 00 F4 00
NOTE: screenshot is confusing, original is on the right, modded on the left.
I think I mostly understand what's happening in the table. How to interpret/map the changes you made here is still black magic.
At least I'll have something to point folks to when they ask me about undervolting that takes effect on all OSs (AKA properly undervolting via VBIOS offset mods.)