Thanks for sharing! Cool technique, until now it's only been possible to do this trick with EVC via external i2c bus and this looks like a good no-soldering option.

 

I tested the theory that current gain values for lower power rails doesn't matter. I first set current gain value for all to 0, but computer crashed. Then I set them to 1 and seemed fine.
I then tested with Kombustor for max current draw from GPU, and made this screenshot:

Current/power reporting completely broke for Vusr/Vmem/Vddci, and Vsoc shows up at 0.2A under full load.
This makes the GPU draw max TDC, since TDP doesn't apply anymore with all minor rails power draw missing from total, and Vgfx current is capped at 308.8A from current gain value for Vgfx rail.

Board stock TDC limit is 220A. I adjusted the stock Vgfx current gain value /1.404 so 220A*1.404=308.8A, which is what is shown for Vgfx current (with x1.404 in HWinfo for that field, so I see the real current value). GPU thinks it's 220A, but it's actually 308.8A. So only TDC limit applies at this point.
Hotspot is a bit higher by 3C as there's 10A or so extra on Vgfx. But memory temps are the same, 70C, nothing changed.
Also 220A (what GPU thinks it's at) *0.932V core voltage = 205W. So it can't hit TDP anymore in this state, will always stay in TDC limit. This will be the case until core voltage reaches 1.2V, at which point it will move in TDP limit.
But increasing current gain value even more, for Vgfx, will get past it again. Up to VRM limit. Since TDP is also applied by limiting Vgfx current. So just up the current from current gain value, on Vgfx, you still get more current even in TDP limit, and higher than 1.2V on Vgfx.

So current gain values for minor rails are irrelevant, they don't do anything even when set to 1 as value, from 338/401/668/401 values they had before. They should have pulled a lot of extra current but they don't. Instead current/power reporting completely broke for them 😀. Voltage reporting still works, and voltages seem the same for those rails. Nothing seems to have changed apart from broken HWinfo reporting. 3 of them completely disappeared from HWinfo, only Vsoc remains.
I can now theoretically keep lowering Vgfx current gain value and increase max current up to VRM limits. But 300A is my limit on stock cooler and stock thermal paste, don't like more than 100C on hotspot.

 

Ran Cyberpunk benchmark today, Buildzoid got me curious, so I ran the same settings, 1440p with default settings on Ultra (no RT). I ran it on Linux.
This run was with stock settings, didn't touch anything, no tweaking, no UV, no increased power limit.

This run was with undervolt/OC/max power limit, but no current gain/VID mods.

And this run was with everything I could throw at it, so far, VID offsets on all 5 rails, OC, everything.

I had a better run but didn't take a screenshot, almost 130fps average. I could probably get a bit more but not sure how much, 2-3 fps average, at most.
This run was with 2870MHz for VRAM, 1.485V with VID offset, +35mV VID offset for Vddci (helps memory), -20mV VID offset on Vgfx, +25mV VID on Vsoc and +10mV on Vddc_usr.

 

Tested some more today. I exhausted tweaking the other rails and memory, the only thing left is figuring out VID offset for Vgfx rail. So I decided to test extremes.
I settled at -70mV VID offset for Vgfx, that seems to work fine. Lower and it crashes. But -70mV worked in Steel Nomad testing and Cyberpunk. No issues.
-70mV is best bang for the heat, maximum performance for least heat.

Undervolt slider doesn't need to change between no VID offset and any +/- VID offset. Crashes at same low value with or without VID offset, which is strange.
At such low Vgfx voltage maximum clock can be at 5000MHz, and minimum clock can be no higher than 2950 for Steel Nomad. And it runs at just under 3000MHz. If you force the GPU at higher than 3000MHz clocks it crashes. So low VID voltage means lower clocks overall. And lower current, and lower heat of-course. But still pretty high performance.
I ran Cyberpunk at -70mV:

Lost 1-2fps average compared to -20mV VID offset run from yesterday. But temps were like 80C max.

Then I tried the other way, +50mV VID offset. I do not have the heat removal capacity for more. I don't think I can max it out anyway.
I got this score:

And I couldn't max the clocks, this was at 3050MHz. I can push it higher but already hitting 110C limit at times. Clearly needs a waterblock for more clocks and higher positive VID offset.
LLC/droop control could help with the heat and still keep performance. Hope I can make it work on RDNA3.

Also improved score on Steel Nomad Vulkan:

This is the best run so far, was at +50mV VID offset, 3100MHz max clocks. But 108C peak temps for hotspot. All HWinfo values are accurate apart from TGP/TBP/GPU Power Maximum (I'll completely remove this last one).
We can calculate TGP and TBP. TGP is all rails powers added up, 402.72W. Difference between HWinfo reported TGP and TBP is accurate, that's 39.37W. Added to TGP we get a TBP of 442W. Quite high, hence the high hotspot temps.

I tried -70mV VID offset and got 120 points lower score, but 88C temp for hotspot. TGP comes at 336W and TBP at 371W:

So positive VID offset on Vgfx helps with higher clocks and some extra performance, but is very costly in power/heat terms (20C for 120 points). May be worth it for that last extra push for some benchmark, but it's not a realistic daily setting. Ideally you optimize everything else to max before using +VID offset on Vgfx.
Adding positive VID offset requires lowering max clock setting, and min clocks can be increased to push clocks a bit higher. That was my experience with Steel Nomad.
-70mV to +50mV added some 70W. There is some performance gain but not worth it for stock cooling. LLC might change that but unknown atm.

Also VRAM seems fine at 2880MHz in all tests. Once I set VID offset for Vsoc/Vddc_usr/Vmem/Vddci rails I had no issues with it at 2880MHz.
Usually testing at 2500MHz, and then 2880MHz, and when changing to 2880MHz Vsoc voltage changes (goes higher) and messes a bit with working point, I have to lower everything a bit, lower lowest clocks/highest clocks (10-20MHz), and back off the UV by 10mV. Then it works fine with 2880MHz. Tested in Steel Nomad/Cyberpunk/Superposition so far.
Temps also fine for VRAM, even at 1.485V. 81C-85C worst case.

 

Decided to risk and permanently save the modifications to voltage controller, and it worked! Well...sort of. VID offsets got saved, they are now persistent on power off cycles. So you only need to do it once and they're there until you save new values.
What didn't get saved was current gain offset, which is pretty important. I have no clue why. Compared to VID offset, current gain offset is on page 0x02.
The closest voltage controller (dual rail) public datasheet I found, was MP2853.
It has this bit of data in datasheet:

It's the only public datasheet for a dual loop controller that mentions page 2.
For the save command there's this bit:

It only mentions it saves data from pages 0 and 1, to EEPROM.
But page 2 is mentioned as "test mode" something. Don't know if same thing as our page 2.
Still, pretty strange. I tried looking at page 28 from EEPROM (on all three controllers), which should hold data for loop 1, and I can't find the current offset values I have on my voltage controllers at page 2. Pretty strange, have no idea where those values come from. The only place I can find them is at page 2, the address I use to modify them. But don't know how they get populated on that page.
The command I used to save VID offsets was:

i2cset -y 3 0x22 0x15

In this case bus 3 (on my PC) and controller address 0x22. So you'd have to do it for all three controller addresses if you have VID offsets on all of them.
Also a serious warning, I risked it on my board, and worked out fine. Might not work for you. Don't do this if you're not ok with losing your GPU. It might brick it, warranty might notice you modified it. So if you decide to do this, you do this at your own risk, like I did.

 

I made this thread as a continuation of this post:

https://www.overclock.net/posts/29459382/

It's meant for discussing various aspects related to the procedure, findings and questions around the subject.

What it does:
Fully removes power limit from all RDNA3 cards, if your card has MP2856/7 controllers. I think I've seen one RDNA3 card that uses different controllers.

How:
Via Linux atm. You can also use a Linux live usb boot, no need for a Linux install. You just need a live usb boot that has both i2c-tools package and i2c-dev kernel module loaded. I tried CachyOS live usb and fits the bill. Use your preffered distro.

The mod is persistent across reboots but goes away on power off. So you need to reapply it when first powering on your PC.

There is a theoretical way to make the change permanent, but it hasn't yet been tried.
Everything about this is risky, so don't do anything until some simpler/safer method comes along.
If you can live with bricking your GPU then read on.

How the RDNA3 power limit is enforced:
The GPU uses the Vgfx voltage controller reported current for main Vgfx rail to apply the TDP/TDC limit. For my Hellhound 7800XT there's a 220A TDC limit.
When voltage controller reports reaching this current, GPU algorithm throttles the power.
The value you have to alter, mentioned in the above link, is a calibration value for the voltage controller output current. Altering this value will make the controller report a lower (or higher but that's not useful) current value to GPU, thus GPU throttles at higher current, and thus power.

What value should you use instead of stock one?
There's two ways of figuring out what value to use, instead of stock one. There's the extreme overclocking value, which should only be used with a waterblock, and then there's stock cooling solution value, which should be safe(r) for a stock card (!).

Extreme overclocking:
For coming up with a value for extreme overclocking, you'd want to match GPU TDC limit to your main power rail current limit.
For example, my card has a stock 220A limit, and has 8 phases at 70A each for main GFX rail. That means an absolute maximum of 560A total. If we calculate the ratio between max VRM current and GPU enforced limit, that's x2.54. You'd have to lower the calibration value by this factor, such that when the controller reports 220A current to GPU, and GPU starts applying TDC limit, it's actually at 560A.
In my case, this stock calibration value is 0x219A. In binary that's 0b0010000110011010. The calibration value is in the first 11 bits (bit 0 to bit 10, in bold). Converted to decimal that's 410.
Applying the 2.54 conversion factor to 410, it works out at 161. Or 0b10100001 in binary. Ideally you attach the leading 0's so 11 bit long, 0b00010100001.
Now we build the whole hex again, 0b00100 and we attach the calibration value, and whole value comes out at 0b0010000010100001. Converting this value back to hex: 0x20A1 is the new value we need to write back to controller.
With this value, GPU TDC limit will be applied when the controller has an output of 560A on GFX rail. This is the most extreme version. Maybe up the value a bit so you don't hit your VRM limits, even with a waterblock.

For this scenario, you'd want to adjust current gain offset for all other rails. Driver has a max of 263W for TDP which is TBP value in HWinfo. That is made up by all 5 rails power added together.
The limits are TDC/TBP/Temp whichever comes first. Usually TBP comes first, but it's averaged out, so it allows for higher TBP peaks but throttles such that averaged it's 263W max. TDC is hard limit. Same as temp.
Vsoc+Vddc_usr+Vmem+Vddci usually work out at around 80-100W total, maybe more in some scenarios. These eat into the 263W total. So you are left with ~150W that you have to squeeze in the whole TDC current you want the GPU to draw. So without adjusting the other rails current offset, you'd have to adjust the current gain value to a greater factor. 150W fits ~160A max. So you'd have to use 560/160=3.5 factor instead of 2.54, to max out your VRM current while keeping stock current gain values (and thus stock power reporting) for the other 4 rails.
This way, when GPU draws 560A + normal power reporting for other 4 rails it works out at max 263W as far as GPU algorithm is concerned, and doesn't TDP throttle until you hit 560A current draw.
So altering the 4 small rails current gain value won't make them draw more current, it will make Vgfx draw more current.

Stock cooling:
For figuring out a value for stock cooling, you have to try a few values that are lower than stock but higher than the most extreme one (VRM limit). Put the heaviest load on GPU and watch your temps. If you want more, lower the value, test again.
For my GPU that worked out at a scaling factor of 1.404. So 410/1.404=292.
Converting 292 to binary: 0b100100100, but make it 11bits long by adding leading 0's: 0b00100100100, and build the whole 16bit value with the leading 0b00100 so 0b0010000100100100.
Converting to hex: 0x2124.
For a sanity check let's look at all three:
Stock - 0x219A
Max with stock cooling - 0x2124
Max with waterblock - 0x20A1
You may be able to do a bit more than x1.404 with better thermal paste on stock cooler.

Here's a max stress test with this new value for current gain, HWinfo GFX current/power values adjusted with x1.404 multiplier

View attachment 2711204

Stock 220A x 1.404 = ~309A new TDC limit. Under full load sits just below 300A current draw. Hotspot 100C. This is max I'd go with stock thermal paste.
Graphics power is somewhere around 374W. Looking at total board power value, there's around 43W difference vs total graphics power, but the total graphics power value is not correct in HWinfo. The difference between TGP and TBP is correct though. Interesting that TGP is 262W, it's wrong, but it's coincidentally the driver TDP limit of 263W. It's throttled at that max value.
On Linux, the driver allows for 280W max power draw, so using the same 1.404 factor in this example, driver will allow for more current, will probably max out to new TDC limit of 309A.

So real TBP comes at 374+43=417W. Quite a bit more vs stock config. And still manageable by stock cooling.

And that's it, once you write this value to controller, the new limit is active. GPU will draw more power, have more performance.

There's 4 other rails (Vsoc/Vddc_usr/Vmem/Vddci), they also have current gain calibration values, but they never reach the max current limit set in GPU for each of them, so no need to alter their values.

Altering this value will mess with current and thus power reporting for GFX rail, which creeps in TBP and TGP power reporting values.
As a partial fix you can add your offset multiplier (2.54 or 1.404 in above examples, or the custom value that you end up using) in HWinfo for GFX current and power reporting. Brings them back to real values. But total power reports will still be off.

I ran two benchmarks in same conditions, one with stock controller value, the other with 2.54 multiplier, and adjusted HWinfo values for GFX current and power.

This is stock current gain value:
View attachment 2711099

And with altered current gain value at 2.54 multiplier, and current and power reporting adjusted with same multiplier:

View attachment 2711100

Pretty much the same thing, same scores, same averages, current/power for GFX works out the same, but TGB/TBP/GPU Power Maximum are off.
I had a low clock limit so it doesn't TDP/TDC throttle during the benchmark, so modification doesn't result in more performance.

As I mentioned in the begining, there's a theoretical way of making the change permanent (and you could also "permanently" revert back to stock value), by issuing an I2C write command to the controller.
There's no official datasheet for the controllers that are used in the RDNA3 cards, but I found the public datasheet for a similar controller, MP2886A. A few of the addresses seem to match our controllers, I tried the "clear errors" command and it worked.

View attachment 2711105

RDNA3 controllers have a few sort of "RAM" pages, page 0 page 1 and page 2. Page 0 is for live data reporting and active settings for loop1, page 1 the same but for loop 2, and page 2 is some config data for both loops.
They also have an internal EEPROM, where defaults are saved. At startup, data from EEPROM is copied on pages 0,1 and 2.
The current gain offset modification alters the stock value on page 2, and goes away on power off. Next startup it's repopulated with the default value that's stored in the EEPROM.
The above command would theoretically take the data that is on pages 0,1 and 2 and write them as defaults in EEPROM, thus would get restored on next startup.

This could be risky and may brick your GPU!

I'm mostly on Linux as my daily so I just have a script that sets the value on startup. For Windows users it might be a pain to constantly boot in Linux live usb on each start.
Or wait for some Windows software to pop up that sets the current offset value so no need for permanent modification.

Next up there's another way of tweaking your GPU's performance, via VID offsets for each of the 5 rails. This too can also be useful. And risky!

This is the list with addresses of interest for mods:

Current gain offset:
Vgfx: controller 0x22, page 0x02, address 0x08
Vsoc: controller 0x24, page 0x02, address 0x08
Vddc_usr: controller 0x24, page 0x02, address 0x18
Vmem: controller 0x26, page 0x02, address 0x08
Vddci: controller 0x26, page 0x02, address 0x18

VID offsets:
Vgfx : controller 0x22, page 0x00, address 0x23.
Vsoc: controller 0x24, page 0x00, address 0x23
Vddc_usr: controller 0x24, page 0x01, address 0x23
Vmem: controller 0x26, page 0x00, address 0x23
Vddci: controller 0x26, page 0x01, address 0x23

Values are two byte for VID as well, with only bits 0 to 8 (so 9 bits) used. 5mV/LSB.
@hellm explains negative offsets here:

AMD - RED BIOS EDITOR und MorePowerTool - BIOS-Einträge anpassen, optimieren und noch stabiler übertakten | Navi unlimited

Seit AMD mit den Adrenalin-Treibern ab 2020 die Verwendung der SoftPowerPlayTables und damit indirekt auch des MorePowerTools massiv eingeschränkt hat, trauert die Community um den einstigen Übertaktungs-oder Untervoltungs-Bonus, der die Navi-Karten wie eine Radeon RX 5700 (XT) zumindest etwas...

www.igorslab.de

With the mention that as far as I can tell positive VID values translate to positive voltage offset for all rails on RDNA3 controllers. And RDNA4 rails/addresses are different to RDNA3.

LLC control might be possible on RDNA3, atm it's unknown. LLC and VID offsets should work on RDNA4 using this method, but not power limit removal. That is enforced in a different way on RDNA4 and needs hardware modification for removal.

Discuss, ask questions, post results. Do mention if you spot any mistakes in any of the details.

Hello i am the guy from Hwbot here it is easier to text so i see your post with this control on linux a few days ago and was really interested but i got an evc so i hardware modded my 7800 xt with an evc we are really close together when its going to scores so its impressing that its working this way. thats how my gpu looks now.

 

Yeah the software mod should work the same way as EVC, but I didn't change thermal paste, I still have my warranty sticker 😀

But in all honesty I have been carried by my VRAM, through most benchmarks, it's Samsung and I can push it to 2880MHz in some cases. Compensates for lack of better cooling in some benchmarks.

 

Idk why but my answer not send so i didnt really bench Cyberpunk and gonna bench all 3dmark benches today not have unlimited time but gonna see what i can do

 

I made a Linux script that will easily remove RDNA3 GPUs power and current limits (doubles them), and can easily apply VID offsets on any of the 5 rails.
I tested it on CachyOS and Ubuntu usb live boot sticks, and seems to work fine.
Detects if on RDNA3 or RDNA4 GPU, installs i2c-tools, loads i2c_dev module if not loaded.

This can also be used on RDNA4 GPUs to double the GFX TDC limit (330A to 660A). Even with global power limit removed (shorted chip pins) you'd still probably hit TDC limit at some point. So this script could help get max performance out of RDNA4 GPUs by increasing that limit past VRM capability.
VID offsets should work for both RDNA3 and RDNA4 GPUs. Once it detects if RNDA3 or 4 it should map correct rails to voltage regulators for each generation.

At the moment it's for testing purposes only, doesn't actually write the values, just echoes them. I will add the write to voltage regulators function once it's past testing phase. You are welcome to try it and report any issues.

I added VID value limits, -70mV minimum to all rails, max values are: +400mV for GFX, 145mV for VRAM, and 100mV for the other 3 rails.

For current gain offset values it just halves whatever it currently finds in the voltage regulators registries. Thus doubles the TDC limits. For extreme XTX setups doubling might not be enough if you want to go past 1000W, so just run it twice, it will quadruple the TDC limits, that should allow for +1000W power draw.

This only works with RDNA3 GPUs that have mp2857 at 0x22 and mp2856 at 0x24 and 0x26. If they don't the script exits.
RDNA4 GPUs must have mp2868 at 0x22 and 0x24.
Do not try it on multiple GPU setups, script looks for SMU 0 i2c bus, do not know its behavior if it finds more than one SMU 0 bus.

VID offset values logic for RDNA4 GFX rail are still not 100% validated, but script only echoes the values so it should be safe for general testing. Once I'm 100% certain then will add write functions to it.
You can get the script from here:

https://gitlab.com/fpsflow/power_limit_removal/-/raw/main/script.sh

Should be able to get it from linux live usb boot with:

wget https://gitlab.com/fpsflow/power_limit_removal/-/raw/main/script.sh

On Ubuntu user doesn't have access to i2c bus so you need to "sudo su" before and then run it with ./script.sh
Could work on yum/dnf distros but I haven't tested it, i2c-tools install part of script might or might not work on them.

Detected Linux OS
i2c_dev module already loaded
i2c-tools is already installed.
Found i2c bus with SMU 0: i2c-3
Detected RDNA3 GPU
RDNA3 GPU validated successfully!

Please select an option:

1. Double Power\Current Limits
2. Modify VID Offsets
0. Exit

Please select an option:

1. GFX_VID: +0 mV -> +50 mV
2. SoC_VID: +0 mV -> -10 mV
3. USR_VID: +0 mV -> -5 mV
4. VRAM_VID: +0 mV -> +100 mV
5. DDCI_VID: +0 mV -> -5 mV

6. Apply
0. Back

Enter your choice:

Feedback is welcomed!

 

I'm slow so forgive me but could I run the option: 1 to double power/current limits without touching the offsets. I know using offsets is probably better but I have no idea about them so I wouldn't really touch them.

Also what do you mean by it just echoes them?

I will definitely use this come Autumn far too warm to run it now and I don't even live in a hot country but it's still far warmer than the winter time.

 

Yes, you can increase PPT/TDC limits without touching VID. And the other way, you can use VID (just for VRAM for example) without touching your PPT/TDC limits.

At this point the script doesn't actually write the values. I figured I'd wait for feedback from a few people about potential issues before I add the write functionality to it. I'm also still tweaking certain things, for example I'm thinking of adding the possibility of adding your custom VID values in the script at the beginning, by editing the file, so you can run them directly without wasting time manually adding all each time.
Echo means it just prints the values on the screen instead of actually writing them in the GPU. For sanity checks. The values are 16bit hex and people testing should make sure they're the correct ones for their GPU.

 

Would you guys reckon that one would be able benefit from overvolting their vram (SKHynix on a 7900XTX, in my case) to achieve higher clock speeds in a non-benchmarking daily driving scenario?
There seems to be very little information about safe voltages for GDDR6. Sorry if this question is redundant

 

On stock 1.35V for VRAM I could maybe get 2550MHz stable. I went to max of 1.495V and I managed to get a 2890MHz run in Steel Nomad. But usually 2880MHz is fine for most benchmarks. But now I go max 1.485V, no reason really, just feel weird about going 1.5V or over.
I saw people making parallels to DDR voltages, and some DDR comes at 1.45V from factory (OC versions).
Probably +100mV (1.45V) should be "safe" for VRAM, but chips matter a lot I think. I have Samsung chips and they seem to clock high with higher voltage. Not sure about Hynix chips.
At +100mV I was able to do 2800-2850MHz. Should probably be fine for 2800MHz in most scenarios, but again, I could only test with my Samsung chips.

 

The active version of the script is up!
https://gitlab.com/fpsflow/power_limit_removal/-/raw/main/script.sh

I'll start this with a warning: this script modifies data on your GPU's voltage regulators. It is temporary, it goes away on power off of PC (not reboot, power off).
There might be a chance it totally bricks your GPU and voids your warranty (somehow), so if you are using it, you are doing it at your own risk!

Now that we got that out of the way, the script detects if RDNA3 or RDNA4 GPU. For RDNA3 it can increase PPT/TDC limits to whatever values you set.
For RDNA4 it can be useful to increase GFX TDC limit from 330A to as high as you want, but without hardware mod to remove power limit that won't be of much help.
VID offsets can be applied on both RDNA3 and RDNA4 on all rails (5 for RDNA3 and 4 for RDNA4). Useful for tweaking operating points on RDNA3 GPUs, less usefull for GFX on RDNA4 without hardware power limit removal. Can still be useful for VRAM/DDCI/SoC rails tweaking.
With VRAM Samsung chips you can raise the clocks higher (2880MHz in my case). Maybe even with Hynix ones.

I have set some sane limits on the values you can use for VID offsets. They are still pretty high (+400mV on GFX, and 145mV on VRAM), so maybe use VID only if you know what you are doing. Start with small +/- values, see what happens.

The script looks for certain VR models at certain addresses, if you do not have mp2857 at 0x22 and mp2856 at 0x24 and 0x26, the script exits. Some RDNA3 GPUs might not be compatible with the script.
For RDNA4 it checks you have mp2868 at 0x22 and 0x24.

If you download it and run it, it won't do anything:

Detected Linux OS
i2c_dev module already loaded
i2c-tools is already installed.
Found i2c bus with SMU 0: i2c-3
Detected RDNA3 GPU
RDNA3 GPU validated successfully!

User-defined values:

CGO Multiplier: Not Set

GFX_VID: Not Set
Current GFX_VID: +0mV

SoC_VID: Not Set
Current SoC_VID: +0mV

USR_VID: Not Set
Current USR_VID: +0mV

VRAM_VID: Not Set
Current VRAM_VID: +0mV

DDCI_VID: Not Set
Current DDCI_VID: +0mV

No settings provided.
Run script with -m for menu

It detects everything, reads you stock VID offsets on all 5 rails (4 for RDNA4), prints them out and exits.
You can run the script with -m switch ( run "chmod +x script.sh" and then run it with "./script.sh -m", also make sure you have internet access to install missing i2c-tools or bc packages), that gets you to the menu where you can set stuff:

Please select an option:

1. Modify Limits
2. Modify VID Offsets
0. Exit

Enter your choice:

In the first menu you can modify your current gain offset values, it's what increases PPT/TDC limits.

Power/Current Limits Menu:

1. Increase your limits by x2.00
2. Set custom limit scalar
0. Back to Main Menu

Enter your choice:

Scaling for PPT/TDC limits is set at x2 for RDNA3 and x1.5 for RDNA4 (weaker VRMs, higher stock TDC). If you choose option 1 it will increase TGP by two times on RDNA3.
Or you can set a custom scaler if that is not enough (XTX). Either that, either run it 2-3 times with x2.00, it doubles the set limits each time.
Scalar values are between 1.00 and 4.00, use two decimal places.
This can be used to set your GFX TDC limit so it matches your total VRM capacity. For example, my GPU has 220A TDC limit, but has 9 phases on GFX, at 70A each. That means my max VRM capacity is of 630A.
If I want to move the stock TDC limit from 220A to 630A, I'd use 630/220=2.86 so x2.86 scalar. Once that is set, the GPU's TDC limit will kick in at 630A real current draw. Which can be useful as protection for VRM, you're repurposing the TDC limit.

Some RDNA4 cards have 8 phases at 50A, which means 400A max. Stock TDC limit is 330A for GFX, so a x1.20 is recommended in that case, to have TDC limit kick in at 400A. This will only happen if you do the hardware mod for power limit removal anyway.

The script increases only GFX TDC limit on RDNA4, rest don't matter.
On RDNA3 all rails contribute to TGP limit (263W in my 7800XT case). So the script is affecting all 5 rails. This way you can use the same multiplier in HWinfo to get back correct reading for each of the 5 rails, for power and current sensors, and also for TGP. TBP sensor data will be wrong, cannot scale it with same value.

Apart from TBP you can fix the rest that are in this photo, for correct data reporting.

I use a multiplier of 2 for my setup, since I am modifying all rails by x2 in the script. That is enough for me, I never hit 440A or 524W anyway (110C hotspot at ~440W TGP, with stock thermal paste).
For RDNA4 this can be done for GFX rail current/power sensors only.

For VID offset menu:

Please select an option:

1. GFX_VID: +0 mV -> +35 mV
2. SoC_VID: +0 mV -> -5 mV
3. USR_VID: +0 mV -> +5 mV
4. VRAM_VID: +0 mV -> +100 mV
5. DDCI_VID: +0 mV -> +10 mV

6. Apply
0. Back

Enter your choice:

Values on left side are current ones read from each rail, right side is what you set for modification. For +5mV input +5, for -10mV input -10.
After you added the values you want and choose 6, they will apply:

Applying changes:

GFX_VID: +35 mV -> 0x0007
SoC_VID: -5 mV -> 0x01FF
USR_VID: +5 mV -> 0x0001
VRAM_VID: +100 mV -> 0x0014
DDCI_VID: +10 mV -> 0x0002

Please select an option:

1. GFX_VID: +35 mV -> +35 mV
2. SoC_VID: -5 mV -> -5 mV
3. USR_VID: +5 mV -> +5 mV
4. VRAM_VID: +100 mV -> +100 mV
5. DDCI_VID: +10 mV -> +10 mV

6. Apply
0. Back

Enter your choice:

You can start over and change them all to 0. Just input +/-0 for 0mV (didn't have time to make an exception for 0).

Applying changes:

GFX_VID: +0 mV -> 0x0000
SoC_VID: +0 mV -> 0x0000
USR_VID: +0 mV -> 0x0000
VRAM_VID: +0 mV -> 0x0000
DDCI_VID: +0 mV -> 0x0000

Please select an option:

1. GFX_VID: +0 mV -> +0 mV
2. SoC_VID: +0 mV -> +0 mV
3. USR_VID: +0 mV -> +0 mV
4. VRAM_VID: +0 mV -> +0 mV
5. DDCI_VID: +0 mV -> +0 mV

6. Apply
0. Back

Enter your choice:

So this sums up the menu part of the script.
But this would get tiresome if you'd have to do it each time your PC crashes in testing hardcore OC settings. So I made a simpler option, you can just edit the script file, and add your values at the beginning of the script:

#!/bin/bash
# Start script with -m switch for menu.

# User defined values for current gain offset/VID RDNA3/4
#Add multiplier value for increasing TDC/PPT limits, valid values 1 to 4
#Use fractional multipliers to two decimal places, eg 1.73 or 2.00
user_current_gain_offset_multiplier=

#Use value in mV with +/- in front, eg -20 or +35
#+0 or -0 are valid to set 0mV VID offset.

#GFX limits -70 to +400
user_vid_offset_gfx=

#VRAM limits -70 to +145
user_vid_offset_vram=

#SoC limits -70 to +100
user_vid_offset_soc=

#DDCI limits -70 to +100
user_vid_offset_ddci=

#Only for RDNA3:
#USR limits -70 to +100
user_vid_offset_usr=

Just add your multiplier for increasing TDC/PPT limits, and VID offset values in mV ( for example +10 for +10mV or -5 for -5mV, or +/- 0 to set 0mV each time you run it, some RDNA4 come with +5mV on GFX from factory)
The ones you don't want to change just leave empty.
USR rail does not exist on RDNA4, but it's also ignored by the script if it detects RDNA4.
This way you can simply run the script, without the -m switch, and it will apply the values you saved in the script file, and then exit without user input. It's faster than manually setting everything from the menu each time.

I tested it on CachyOS and Ubuntu live boot usb sticks. Works fine on both.
On Ubuntu you have to "sudo su" before, and then run it with ./script.sh.
CachyOS has everything needed, on Ubuntu script will automatically install i2c-tools. You can then reboot in Windows and the mods will carry over. They go away on full power off of PC, so have to be reapplied next time you power on your PC.
edit: Tested with Fedora live usb boot and worked fine. Same as Ubuntu, regular user doesn't have access to i2c bus so "sudo su" before running the script.
I had to mount the first partition of the USB stick so I can save the script on it, same when booting into live, to run it.
You can also directly get the script on Linux with

wget https://gitlab.com/fpsflow/power_limit_removal/-/raw/main/script.sh

And a final warning: after you increase your PPT/TDC limits, your only protection will be the hotspot temperature limit (110C). So take care, after removing the limits check your temperature when running loads, it's not healthy for the GPU to work at >100C hotspot. It will shorten its life.

RDNA4 VRs share the same current gain offset/VID offset registries as RDNA3, but rail assignment is different (apart from GFX and SoC, which are on same VR addresses/loops as RDNA3). Thanks @hellm for helping with two's complement conversion and RDNA4 registry hints.

If you have errors/issues ask here on this thread. Or general questions about how to use it for OC.
Good luck!

 

This is awesome, man.

 

Glad you like it!

Also forgot to mention @fractured for testing which way VID is applied on RDNA4 GFX rail, and also @ShirKhan on Igor's Lab forum (@nilssohn here?) for testing and finding out the VID sign bit for RDNA4.

 

I better get the beers in for some weekend shenanigans.

 

For people who daily Linux, there's a mp2856 kernel driver, which offers hwmon data. You can monitor your VRs rails data on Linux.

Once you expose them on hwmon, you cannot use the script. The VRs are busy, and i2cget/i2cset commands will fail. You have to remove the hwmon interfaces before using the script or sending i2cget/i2cset commands.

The way to expose them on hwmon is using these commands:

echo mp2856 0x22 > /sys/class/i2c-dev/i2c-3/device/new_device

echo mp2856 0x24 > /sys/class/i2c-dev/i2c-3/device/new_device

echo mp2856 0x26 > /sys/class/i2c-dev/i2c-3/device/new_device

Note that this is for i2c-3 bus, in my case. Adjust to your setup.
For RDNA4 only 0x22 and 0x24 are needed.
You should now see them if running the "sensors" command.

The way you remove them is:

echo 0x22 > /sys/class/i2c-dev/i2c-3/device/delete_device

echo 0x24 > /sys/class/i2c-dev/i2c-3/device/delete_device

echo 0x26 > /sys/class/i2c-dev/i2c-3/device/delete_device

For RDNA4 the same driver works to some degree, but hasn't been properly confirmed.

The stock driver has some mistakes, and is not complete. Bellow is a patch for the driver that shows more than 8 phases for GFX, and seems to correctly show the per-phase current draw for GFX, but I have tweaked the values for my 7800XT. I am not sure if all GPUs share the same Kcs/Rcs values on RDNA3, or RDNA4.
The stock driver is locked on 8 phases max. The patch makes the driver read the actual phase configuration from your VRs, and show up to 12 phases if you have them.
This driver gives you current/voltage/temperature reading for all rails, on Linux. But it's far from perfect atm.

diff --git a/drivers/hwmon/pmbus/mp2856.c b/drivers/hwmon/pmbus/mp2856.c
index e83c70a..59e23e9 100644
--- a/drivers/hwmon/pmbus/mp2856.c
+++ b/drivers/hwmon/pmbus/mp2856.c
@@ -42,7 +42,7 @@
#define MP2856_MAX_PHASE_RAIL2        4

#define MP2857_MAX_PHASE_RAIL1        12
-#define MP2857_MAX_PHASE_RAIL2        4
+#define MP2857_MAX_PHASE_RAIL2        6

#define MP2856_PAGE_NUM            2

@@ -153,7 +153,8 @@ mp2856_read_phase(struct i2c_client *client, struct mp2856_data *data,
     /*
      * Output value is calculated as: (READ_CSx * 12.5mV - 1.23V) / (Kcs * Rcs)
      */
-    val = (ret * 125) - 12300;
+    /* val = (ret * 125) - 12300; */
+    val = (((ret * 125) - 12300) * 10000) / (data->curr_sense_gain[page] * 11);

     return val2linear11(val);
}
@@ -182,6 +183,14 @@ mp2856_read_phases(struct i2c_client *client, struct mp2856_data *data,
             ret = mp2856_read_phase(client, data, page, phase,
                         MP2856_MFR_READ_CS7_8_R1);
             break;
+                case 8 ... 9:
+                        ret = mp2856_read_phase(client, data, page, phase,
+                                                MP2856_MFR_READ_CS9_10_R1);
+                        break;
+                case 10 ... 11:
+                        ret = mp2856_read_phase(client, data, page, phase,
+                                                MP2856_MFR_READ_CS11_12_R1);
+                        break;
         default:
             return -ENODATA;
         }
@@ -193,8 +202,12 @@ mp2856_read_phases(struct i2c_client *client, struct mp2856_data *data,
             break;
         case 2 ... 3:
             ret = mp2856_read_phase(client, data, page, phase,
-                        MP2856_MFR_READ_CS1_2_R2);
+                        MP2856_MFR_READ_CS3_4_R2);
             break;
+                case 4 ... 5:
+                        ret = mp2856_read_phase(client, data, page, phase,
+                                                MP2856_MFR_READ_CS5_6_R2);
+                        break;
         default:
             return -ENODATA;
         }
@@ -264,7 +277,7 @@ mp2856_identify_multiphase_rail1(struct i2c_client *client,
     int ret, i;

     ret = mp2856_identify_multiphase(client, MP2856_MFR_VR_MULTI_CONFIG_R1,
-                     MP2856_MAX_PHASE_RAIL1, GENMASK(3, 0));
+                     data->max_phases[0], GENMASK(3, 0));
     if (ret < 0)
         return ret;

@@ -284,7 +297,7 @@ mp2856_identify_multiphase_rail2(struct i2c_client *client,
     int ret, i;

     ret = mp2856_identify_multiphase(client, MP2856_MFR_VR_MULTI_CONFIG_R2,
-                     MP2856_MAX_PHASE_RAIL2, GENMASK(2, 0));
+                     data->max_phases[1], GENMASK(2, 0));
     if (ret < 0)
         return ret;

If anyone tests it, please report results.

This is the info I get in my case:

❯ sensors mp2857-i2c-3-22 mp2856-i2c-3-24 mp2856-i2c-3-26
mp2857-i2c-3-22
Adapter: AMDGPU SMU 0
vin:          11.50 V  (crit min = -2748416.00 V, min = -494.00 V)
                       (max = -3833856.00 V, crit max = +16.00 V)
                       (rated min = +512.00 V, rated max =  +0.00 V)
vout1:       636.00 mV (crit min =  +0.02 V, min =  +0.00 V)
                       (max =  +0.00 V, crit max =  +0.00 V)
                       (rated min =  +0.08 V, rated max =  +0.09 V)
temp1:        +41.0°C  (low  = +255.0°C, high = +150.0°C)
                       (crit low = -1022.0°C, crit = +170.0°C)
pin:           0.00 W  (max =   2.05 W, rated max =   0.00 W)
pout1:         0.00 W  (max =   1.56 kW, crit =   2.00 W)
                       (rated max =   0.00 W)
iin:           0.00 A  (max = +99.00 A, crit max = -164096.00 A)
                       (rated max =  +0.00 A)
iout1:         0.00 A  (crit min = +143.00 A, max = +20.00 A)
                       (crit max =  +0.00 A, rated max =  +0.00 A)
iout1.0:     -910.00 mA
iout1.1:     -910.00 mA
iout1.2:     -910.00 mA
iout1.3:     -910.00 mA
iout1.4:       1.36 A
iout1.5:       1.36 A
iout1.6:       1.36 A
iout1.7:       1.36 A
iout1.8:       1.36 A

mp2856-i2c-3-24
Adapter: AMDGPU SMU 0
vin:          11.56 V  (crit min = -2748416.00 V, min = -474.00 V)
                       (max = -3833856.00 V, crit max = +16.00 V)
                       (rated min = -1024.00 V, rated max =  +0.00 V)
vout1:       687.00 mV (crit min =  +0.02 V, min =  +0.00 V)
                       (max =  +0.00 V, crit max =  +0.00 V)
                       (rated min =  +0.09 V, rated max =  +0.09 V)
vout2:       738.00 mV (crit min =  +0.03 V, min =  +0.13 V)
                       (max =  +0.17 V, crit max =  +0.52 V)
                       (rated min =  +0.10 V, rated max =  +0.10 V)
temp1:        +39.0°C  (low  = +255.0°C, high = +150.0°C)
                       (crit low = -1022.0°C, crit = +170.0°C)
temp2:        +40.0°C  (low  = +8355840.0°C, high =  +0.0°C)
                       (crit low = -1024.0°C, crit = +574464.0°C)
pin:           0.00 W  (max =   2.05 W, rated max =   0.00 W)
pout1:        16.00 W  (max =   2.08 kW, crit =   2.00 W)
                       (rated max =   0.00 W)
pout2:         0.00 W  (max =   2.08 kW, crit =   2.00 W)
                       (rated max =   0.00 W)
iin:           0.00 A  (max = +99.00 A, crit max = -164096.00 A)
                       (rated max =  +0.00 A)
iout1:       750.00 mA (crit min = +155.00 A, max = +24.00 A)
                       (crit max =  +0.00 A, rated max =  +0.00 A)
iout1.0:     -910.00 mA
iout1.1:       1.36 A
iout2:       625.00 mA (crit min = +260.00 A, max = +93.00 A)
                       (crit max = +87.00 A, rated max =  +0.00 A)
iout2.0:     -910.00 mA

mp2856-i2c-3-26
Adapter: AMDGPU SMU 0
vin:          11.56 V  (crit min = -2748416.00 V, min = -494.00 V)
                       (max = -3833856.00 V, crit max = +16.00 V)
                       (rated min = -512.00 V, rated max =  +0.00 V)
vout1:         1.23 V  (crit min =  +0.13 V, min =  +0.00 V)
                       (max =  +0.00 V, crit max =  +0.00 V)
                       (rated min =  +0.20 V, rated max =  +0.22 V)
vout2:       667.00 mV (crit min =  +0.02 V, min =  +0.13 V)
                       (max =  +0.17 V, crit max =  +0.52 V)
                       (rated min =  +0.08 V, rated max =  +0.09 V)
temp1:        +41.0°C  (low  = +255.0°C, high = +150.0°C)
                       (crit low = -1022.0°C, crit = +170.0°C)
temp2:        +40.0°C  (low  = +8355840.0°C, high =  +0.0°C)
                       (crit low = -1024.0°C, crit = +576512.0°C)
pin:         1000.00 mW (max =   2.05 W, rated max =   0.00 W)
pout1:        56.00 W  (max =   2.08 kW, crit =   2.00 W)
                       (rated max =   0.00 W)
pout2:         0.00 W  (max =   2.08 kW, crit =   2.00 W)
                       (rated max =   0.00 W)
iin:         125.00 mA (max = +500.00 A, crit max = +65280.00 A)
                       (rated max =  +0.00 A)
iout1:         2.62 A  (crit min = +76288.00 A, max = +236.00 A)
                       (crit max =  +0.00 A, rated max =  +0.00 A)
iout1.0:       1.36 A
iout1.1:       3.64 A
iout2:       250.00 mA (crit min = +260.00 A, max = +93.00 A)
                       (crit max = +87.00 A, rated max =  +0.00 A)
iout2.0:     -910.00 mA

Per-phase current reporting is not accurate at low power levels, but seems fine at higher power levels.

iout1/iout2 is total for each rail, and that should be accurate. iout1.0 etc is per phase. iout1 is loop 1 and iout2 is loop 2 of VR.

 

Dunno if anyone has tried this, but the script actually executes under WSL (Windows Subsystem for Linux) it

"Loaded i2c_dev module
Hit:1 http://archive.ubuntu.com/ubuntu jammy InRelease
Get:2 http://archive.ubuntu.com/ubuntu jammy-updates InRelease [128 kB]
Get:3 http://archive.ubuntu.com/ubuntu jammy-backports InRelease [127 kB]
Get:4 http://archive.ubuntu.com/ubuntu jammy/universe amd64 Packages [14.1 MB]
Get:5 http://security.ubuntu.com/ubuntu jammy-security InRelease [129 kB]
Get:6 http://archive.ubuntu.com/ubuntu jammy/universe Translation-en [5652 kB]
Get:7 http://archive.ubuntu.com/ubuntu jammy/universe amd64 c-n-f Metadata [286 kB]
Get:8 http://archive.ubuntu.com/ubuntu jammy/multiverse amd64 Packages [217 kB]
Get:9 http://archive.ubuntu.com/ubuntu jammy/multiverse Translation-en [112 kB]
Get:10 http://archive.ubuntu.com/ubuntu jammy/multiverse amd64 c-n-f Metadata [8372 B]
Get:11 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages [2623 kB]
Get:12 http://archive.ubuntu.com/ubuntu jammy-updates/main Translation-en [423 kB]
Get:13 http://archive.ubuntu.com/ubuntu jammy-updates/main amd64 c-n-f Metadata [18.5 kB]
Get:14 http://archive.ubuntu.com/ubuntu jammy-updates/restricted amd64 Packages [3638 kB]
Get:15 http://archive.ubuntu.com/ubuntu jammy-updates/restricted Translation-en [648 kB]
Get:16 http://archive.ubuntu.com/ubuntu jammy-updates/restricted amd64 c-n-f Metadata [676 B]
Get:17 http://archive.ubuntu.com/ubuntu jammy-updates/universe amd64 Packages [1208 kB]
Get:18 http://archive.ubuntu.com/ubuntu jammy-updates/universe Translation-en [298 kB]
Get:19 http://archive.ubuntu.com/ubuntu jammy-updates/universe amd64 c-n-f Metadata [28.7 kB]
Get:20 http://archive.ubuntu.com/ubuntu jammy-updates/multiverse amd64 Packages [46.5 kB]
Get:21 http://archive.ubuntu.com/ubuntu jammy-updates/multiverse Translation-en [11.8 kB]
Get:22 http://archive.ubuntu.com/ubuntu jammy-updates/multiverse amd64 c-n-f Metadata [592 B]
Get:23 http://archive.ubuntu.com/ubuntu jammy-backports/main amd64 Packages [68.8 kB]
Get:24 http://archive.ubuntu.com/ubuntu jammy-backports/main Translation-en [11.4 kB]
Get:25 http://archive.ubuntu.com/ubuntu jammy-backports/main amd64 c-n-f Metadata [392 B]
Get:26 http://archive.ubuntu.com/ubuntu jammy-backports/restricted amd64 c-n-f Metadata [116 B]
Get:27 http://archive.ubuntu.com/ubuntu jammy-backports/universe amd64 Packages [30.0 kB]
Get:28 http://archive.ubuntu.com/ubuntu jammy-backports/universe Translation-en [16.5 kB]
Get:29 http://archive.ubuntu.com/ubuntu jammy-backports/universe amd64 c-n-f Metadata [672 B]
Get:30 http://archive.ubuntu.com/ubuntu jammy-backports/multiverse amd64 c-n-f Metadata [116 B]
Get:31 http://security.ubuntu.com/ubuntu jammy-security/main amd64 Packages [2375 kB]
Get:32 http://security.ubuntu.com/ubuntu jammy-security/main Translation-en [359 kB]
Get:33 http://security.ubuntu.com/ubuntu jammy-security/main amd64 c-n-f Metadata [13.6 kB]
Get:34 http://security.ubuntu.com/ubuntu jammy-security/restricted amd64 Packages [3513 kB]
Get:35 http://security.ubuntu.com/ubuntu jammy-security/restricted Translation-en [628 kB]
Get:36 http://security.ubuntu.com/ubuntu jammy-security/restricted amd64 c-n-f Metadata [624 B]
Get:37 http://security.ubuntu.com/ubuntu jammy-security/universe amd64 Packages [974 kB]
Get:38 http://security.ubuntu.com/ubuntu jammy-security/universe Translation-en [210 kB]
Get:39 http://security.ubuntu.com/ubuntu jammy-security/universe amd64 c-n-f Metadata [21.7 kB]
Get:40 http://security.ubuntu.com/ubuntu jammy-security/multiverse amd64 Packages [39.6 kB]
Get:41 http://security.ubuntu.com/ubuntu jammy-security/multiverse Translation-en [8716 B]
Get:42 http://security.ubuntu.com/ubuntu jammy-security/multiverse amd64 c-n-f Metadata [368 B]
Fetched 38.0 MB in 3s (11.3 MB/s)
Reading package lists... Done
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
libi2c0 libx86-1 read-edid
Suggested packages:
libi2c-dev python3-smbus
The following NEW packages will be installed:
i2c-tools libi2c0 libx86-1 read-edid
0 upgraded, 4 newly installed, 0 to remove and 199 not upgraded.
Need to get 184 kB of archives.
After this operation, 715 kB of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu jammy/universe amd64 libi2c0 amd64 4.3-2build1 [6608 B]
Get:2 http://archive.ubuntu.com/ubuntu jammy/universe amd64 libx86-1 amd64 1.1+ds1-12 [77.3 kB]
Get:3 http://archive.ubuntu.com/ubuntu jammy/universe amd64 read-edid amd64 3.0.2-1.1 [19.0 kB]
Get:4 http://archive.ubuntu.com/ubuntu jammy/universe amd64 i2c-tools amd64 4.3-2build1 [80.8 kB]
Fetched 184 kB in 0s (1489 kB/s)
Selecting previously unselected package libi2c0:amd64.
(Reading database ... 24075 files and directories currently installed.)
Preparing to unpack .../libi2c0_4.3-2build1_amd64.deb ...
Unpacking libi2c0:amd64 (4.3-2build1) ...
Selecting previously unselected package libx86-1:amd64.
Preparing to unpack .../libx86-1_1.1+ds1-12_amd64.deb ...
Unpacking libx86-1:amd64 (1.1+ds1-12) ...
Selecting previously unselected package read-edid.
Preparing to unpack .../read-edid_3.0.2-1.1_amd64.deb ...
Unpacking read-edid (3.0.2-1.1) ...
Selecting previously unselected package i2c-tools.
Preparing to unpack .../i2c-tools_4.3-2build1_amd64.deb ...
Unpacking i2c-tools (4.3-2build1) ...
Setting up libx86-1:amd64 (1.1+ds1-12) ...
Setting up libi2c0:amd64 (4.3-2build1) ...
Setting up read-edid (3.0.2-1.1) ...
Setting up i2c-tools (4.3-2build1) ...
Failed to send reload request: No such file or directory
Processing triggers for man-db (2.10.2-1) ...
Processing triggers for libc-bin (2.35-0ubuntu3.1) ...
Installed i2c-tools
No i2c bus with "SMU 0" found."

I ran it on my notebook without an AMD GPU just to see if it launches, and it actually does. Will try later this week on my AMD GPU powered PC

 

I tried it but WSL doesn't expose the i2c bus sadly. I remember reading somewhere that it's not designed to, so not sure you can hack it somehow. But do try.
I made some progress on permanently saving the power limit increase, but don't yet have a solution. Still need to solve something for that, not sure when or if I manage it.
This way you'd only need to use it once to permanently increase your power limits.
VID offsets can be permanently saved atm (script doesn't offer the option to), but that's not as useful without the permanent power limit increase, so it doesn't reset to stock on PC power off.

 

Forgot to mention that this is for desktop class RDNA3/4 GPUs. On laptops the script will most likely fail validation, as they probably won't use the same VRs.
I could try and work with someone who has laptop class RDNA3/4 but the issue with laptops it they have zero TDP margins, they're already saturated in stock config. You won't get much extra, if anything.

 

You need to get me again i think its possible can you try it ? I scored 47 674 in Wild Life Extreme

 

I now have a solution to permanently save current gain offsets, as well as VID, and any other possible modification to VRs (will look into LLC for RDNA3).
It is not yet implemented in the script, and it will take a while to test. It might also work for RDNA4 to permanently increase GFX TDC limit to whatever limit you want, like the script does at the moment.
I will update after more testing is done, but I have now successfully booted fine with permanently saved custom current gain offset values! You will only need to run the script once and that's it!
🥳 🚀🚀

 

Just stumbled upon this after googling your username from the GravityMark 7800XT benchmarks. Looking forward to trying it out!

 

I prefer it temporary but fair play to you getting it permanently saved. The reason I prefer temp is I own my 7900 XTX since launch and it's still on original paste and air cooler. I already flashed the 550W extreme bios and that is too much for my card I have to go into the negative on the power limits as it's too much for my cards cooling so permanently having high power limits would be a bad idea for my card.

 

Yes of-course, both aproaches have their uses. The permanent modification version will be a separate script for people interested in that.
For example, on RDNA4 if you short the power monitoring chips on the PCB, you still have the TDC limit. Some people might want to permanently increase the TDC limit as well, without having to use the script each time. Depends from case to case, so will probably be a separate script for permanent modifications.
You can always restore back to stock values, permanently.

edit: For RDNA4 it might not be so simple. @PJVol made a dump of page 0x2a and it's full of 0x0000, so it's most likely locked. Once we can unlock it, then we can probably modify it the same as I did on RDNA3. Will update if anything changes for RDNA4.

 

Thank you. Excellent work. I have one very simple question, which is just for clarification purpose before I try any of this:

Will it work in a Windows 10 environment only, without the use of any linux of other OS subsystems.
Thanks again.

 

You can already try it, there's the ephemeral mod version, goes away on PC power off. But is persistent across reboots. That works fine now.
Check this post for it:

https://www.overclock.net/posts/29473161/

What I'm working on right now is the permanent modification version, which might suit some people. Like boost the max power limit by 50W-100W, maybe add some VRAM voltage and that's it. Don't have to boot into Linux first to apply it, it's ready to go in Windows/Linux anytime you power your PC.

 

Script is done, and it's working fine. I modified both current gain offsets and VID offsets, powered PC off. Powered it back on and mods were still there. Has a bunch of checks, and I use CRC checking for both dumped data and written data. Have to as this is a bit different to the ephemeral mod.
Restoring to stock config also works fine. There's a stock data backup in the EEPROM, and I can use those values to revert to stock (probably works on all RDNA3 GPUs), and also figure out by how much your current power level is set at, supposing you already used the script before, and saved some whatever power increase, script detects by how much it already is vs your stock values, and can revert to your stock config at any time.
If you didn't use it before, it will show an active power multiplier of x1.00, as you are stock.
Permanent VID offsets work as well.

I will keep testing it for 1-2 days before I release it, I just want to make sure I covered all bases, and all edge case scenarios that might happen.
Also added some small delays between writes, just to make sure nothing funny can happen.

 

This is great. I have been on the fence about buying the latest AMD XT card. (Was hoping they would offer a true enthusiast class card that was somewhere between, RTX4080super - RTX 4090 performance.) Not interested in Blackwell.

Thanks is all I wanted to say.

Edit: Of course no rush at all!