OP reconstructed, some attachments/links still need resolving.
Last update: 29/10/18
Warning: Using this guide to edit your bios will void your warranty (if card has one). This guide is provided assuming a user knows implications of what they are doing. I accept no responsibility for damage from using this information. All efforts are being made to double check information but there maybe errors.
Make backup of original bios on video card, for each switch position.
Edit copies of your original bios, so you always have original unedited bios to use if things go bad.
Do not flash both bios positions, if something goes wrong you can use other switch position to boot and then change switch position and flash over bad ROM.
GPU-Z latest versions supports full VEGA ROM saving.
Support for flashing VEGA is only in AtiWinFlash v2.77 onwards. For flashing in W10 1803, AtiWinFlash v2.84 is needed (see TPU downloads section).
VEGA FE has a security feature to check VBIOS at post using a on die HW implementation, so modded VBIOS regardless of flash method is not working at present. RX VEGA also has this protection.
Flashing of unmodified VBIOS is functioning:-
i) RX VEGA editions can be flashed to another RX VEGA edition.
ii) VEGA FE editions can be flashed to another VEGA FE edition.
iii) Cross flashing between RX VEGA and VEGA FE is not possible.(Recently a 8GB FE VBIOS has surfaced this allows RX VEGA to be FE, link)
UEFI/GOP module can be updated, see Lordkag's tool in relevant section, also a shout to all that kept the tool going in his absence and special thanks to facilitator Fernado of Win-Raid Forum!
Essentials
(Note: Some links still to be fixed)
https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_pptable.h
AtomBiosReader by Kizwan as in OP of Hawaii/Fiji bios editing OP
VEGA FE AIR shared by jstefanop
VEGA FE AIR with The Stilt's i2c comms unlock
VEGA FE LIQUID VBIOS on TPU
RX VEGA 56 AIR shared by Buildzoid
RX VEGA 64 AIR full ROM shared by Sicness
RX VEGA 64 AIR with The Stilt's i2c comms unlock
RX VEGA 64 AIO full ROM by kundica
RX VEGA 64 AIO V016.001.001.000.008774 by asder00
RX VEGA 64 Strix full ROM by hellm
VEGA_Soft_PP.zip 4k .zip file .
Hellm has created SoftPowerPlayTable key files. This PowerPlay in registry the driver will give priority over firmware PowerPlay. This is the same as on past cards where we used 'Extend Official Overclocking Limits' in MSI AB. It is a known workaround which does not cause issues to OS/driver. The registry PowerPlay can be modified like we would the VBIOS one, I will add guide soon, for now reference Linux VEGA PP linked above, info below and Hellm's post here and here.
Creating your own PowerPlay reg file
Useful links
RTG - Vega Whitepaper
https://en.wikipedia.org/wiki/Endianness
https://docs.mql4.com/basis/types/integer/integertypes
https://en.wikipedia.org/wiki/Byte
[Official] Vega Frontier / RX Vega Owners Thread
PCPer - Radeon Vega Frontier Edition GPU and PCB Exposed
Halsafar has created Vega64SoftPowerTableEditor, link to repository, link to compiled release and post within this thread. (Note: GTK# for .NET needed for app to work.)
Warning to VEGA FE owners GFX clocks section in Vega64SoftPowerTableEditor is not correct, only do PP mod reg edit by hand.
Viewing of VBIOS so far.
Testing of PowerPlay registry mods
Updating UEFI/GOP module in VBIOS
Will be looking add other sections and VBIOS info soon as and when required . So do check OP for updates, usually I will bump thread with a post .
Last update: 29/10/18
Warning: Using this guide to edit your bios will void your warranty (if card has one). This guide is provided assuming a user knows implications of what they are doing. I accept no responsibility for damage from using this information. All efforts are being made to double check information but there maybe errors.
Make backup of original bios on video card, for each switch position.
Edit copies of your original bios, so you always have original unedited bios to use if things go bad.
Do not flash both bios positions, if something goes wrong you can use other switch position to boot and then change switch position and flash over bad ROM.
GPU-Z latest versions supports full VEGA ROM saving.
Support for flashing VEGA is only in AtiWinFlash v2.77 onwards. For flashing in W10 1803, AtiWinFlash v2.84 is needed (see TPU downloads section).
VEGA FE has a security feature to check VBIOS at post using a on die HW implementation, so modded VBIOS regardless of flash method is not working at present. RX VEGA also has this protection.
Flashing of unmodified VBIOS is functioning:-
i) RX VEGA editions can be flashed to another RX VEGA edition.
ii) VEGA FE editions can be flashed to another VEGA FE edition.
iii) Cross flashing between RX VEGA and VEGA FE is not possible.(Recently a 8GB FE VBIOS has surfaced this allows RX VEGA to be FE, link)
UEFI/GOP module can be updated, see Lordkag's tool in relevant section, also a shout to all that kept the tool going in his absence and special thanks to facilitator Fernado of Win-Raid Forum!
Essentials
(Note: Some links still to be fixed)
https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_pptable.h
AtomBiosReader by Kizwan as in OP of Hawaii/Fiji bios editing OP
VEGA FE AIR shared by jstefanop
VEGA FE AIR with The Stilt's i2c comms unlock
VEGA FE LIQUID VBIOS on TPU
RX VEGA 56 AIR shared by Buildzoid
RX VEGA 64 AIR full ROM shared by Sicness
RX VEGA 64 AIR with The Stilt's i2c comms unlock
RX VEGA 64 AIO full ROM by kundica
RX VEGA 64 AIO V016.001.001.000.008774 by asder00
RX VEGA 64 Strix full ROM by hellm
VEGA_Soft_PP.zip 4k .zip file .
Hellm has created SoftPowerPlayTable key files. This PowerPlay in registry the driver will give priority over firmware PowerPlay. This is the same as on past cards where we used 'Extend Official Overclocking Limits' in MSI AB. It is a known workaround which does not cause issues to OS/driver. The registry PowerPlay can be modified like we would the VBIOS one, I will add guide soon, for now reference Linux VEGA PP linked above, info below and Hellm's post here and here.
Creating your own PowerPlay reg file
Useful links
RTG - Vega Whitepaper
https://en.wikipedia.org/wiki/Endianness
https://docs.mql4.com/basis/types/integer/integertypes
https://en.wikipedia.org/wiki/Byte
[Official] Vega Frontier / RX Vega Owners Thread
PCPer - Radeon Vega Frontier Edition GPU and PCB Exposed
Halsafar has created Vega64SoftPowerTableEditor, link to repository, link to compiled release and post within this thread. (Note: GTK# for .NET needed for app to work.)
Warning to VEGA FE owners GFX clocks section in Vega64SoftPowerTableEditor is not correct, only do PP mod reg edit by hand.
Viewing of VBIOS so far.
First thing that grabbed me was PowerPlay size is so close to Tonga / Fiji / Polaris, but Rev 08:01 vs Rev 07:01 in the prior mentioned GPUs.
PowerPlay header:
VEGA PowerPlay has OD limits as:-
ODMemoryClock on Fiji was 500MHz, ie it's stock speed, perhaps there will be headroom in this aspect :thinking: . What scaling!? it wasn't much on Fiji going from say 500MHz to 545MHz in case situations I tested.
By the OD limits we have 50% PL limit.
MCLK_Dependency_Table
MclkDependencyTable, min 167MHz HBM max 945MHz, 4 states. Fiji had only 1 HBM state (500MHz), it was possible to modify PowerPlay to have more (video/post in Fiji bios mod).
Gfxclk_Dependency_Table
GfxclkDependencyTable, min 852MHz max 1600MHz, 8 states.
Vddc/Vddmem LookupTable
Viewing VddcLookupTable, lowest state as 800mV, which is 100mV lower than stock Fiji. Highest state is 1200mV. How this lookup table is used for when ASIC profiling is done no idea at present, Fiji max 1250mV.
VddmemLookupTable has 1350mV, no idea if this is HBM voltage or something else. Fiji did not have HBM voltage in PowerPlay, nor was it 1.2V, but 1.3V. Not read about HBM2 at all TBH, but would have expected it lower or 1.3V, perhaps AMD needed to give it a bump if this values is indeed that.
PowerTune_Table
Ref'ing the Linux info, there are 2 slightly differing setups of PowerTune, one I believe is for the AIO version and the other for AIR version. PowerTune_Table_V2 I believe is for the AIR version.
HBM2 has a temperature limit in PowerPlay, Fiji did not.
AFAIK HBM1 should also have had a temperature sensor, as JEDEC PDF highlighted with increased temps HBM should lower performance to reduce temps. No monitoring on Fiji showed this temp, either it was not implemented or not exposed for SW to show.
PowerPlay header:
Code:
typedef struct _ATOM_Vega10_POWERPLAYTABLE {
struct atom_common_table_header sHeader;
00 UCHAR ucTableRevision;
5C 00 USHORT usTableSize; /* the size of header structure */
22 07 00 00 ULONG ulGoldenPPID; /* PPGen use only */
03 2B 00 00 ULONG ulGoldenRevision; /* PPGen use only */
1B 00 USHORT usFormatID; /* PPGen use only */
48 00 00 00 ULONG ulPlatformCaps; /* See ATOM_Vega10_CAPS_* */
80 A9 03 00 (2400MHz) ULONG ulMaxODEngineClock; /* For Overdrive. */
F0 49 02 00 (1500MHz) ULONG ulMaxODMemoryClock; /* For Overdrive. */
32 00 USHORT usPowerControlLimit;
08 00 USHORT usUlvVoltageOffset; /* in mv units */
00 00 USHORT usUlvSmnclkDid;
00 00 USHORT usUlvMp1clkDid;
00 00 USHORT usUlvGfxclkBypass;
00 00 USHORT usGfxclkSlewRate;
00 UCHAR ucGfxVoltageMode;
00 UCHAR ucSocVoltageMode;
00 UCHAR ucUclkVoltageMode;
00 UCHAR ucUvdVoltageMode;
00 UCHAR ucVceVoltageMode;
02 UCHAR ucMp0VoltageMode;
01 UCHAR ucDcefVoltageMode;
5C 00 (0x5Ch) USHORT usStateArrayOffset; /* points to ATOM_Vega10_State_Array */
1B 02 (0x21Bh) USHORT usFanTableOffset; /* points to ATOM_Vega10_Fan_Table */
12 02 (0x212h) USHORT usThermalControllerOffset; /* points to ATOM_Vega10_Thermal_Controller */
94 00 (0x94h) USHORT usSocclkDependencyTableOffset; /* points to ATOM_Vega10_SOCCLK_Dependency_Table */
6A 01 (0x16Ah) USHORT usMclkDependencyTableOffset; /* points to ATOM_Vega10_MCLK_Dependency_Table */
B4 00 (0xB4h) USHORT usGfxclkDependencyTableOffset; /* points to ATOM_Vega10_GFXCLK_Dependency_Table */
FE 00 (0xFEh) USHORT usDcefclkDependencyTableOffset; /* points to ATOM_Vega10_DCEFCLK_Dependency_Table */
7A 00 (0x7Ah) USHORT usVddcLookupTableOffset; /* points to ATOM_Vega10_Voltage_Lookup_Table */
8C 00 (0x8Ch) USHORT usVddmemLookupTableOffset; /* points to ATOM_Vega10_Voltage_Lookup_Table */
88 01 (0x188h) USHORT usMMDependencyTableOffset; /* points to ATOM_Vega10_MM_Dependency_Table */
00 00 USHORT usVCEStateTableOffset; /* points to ATOM_Vega10_VCE_State_Table */
00 00 USHORT usReserve; /* No PPM Support for Vega10 */
3E 02 (0x23Eh) USHORT usPowerTuneTableOffset; /* points to ATOM_Vega10_PowerTune_Table */
00 00 USHORT usHardLimitTableOffset; /* points to ATOM_Vega10_Hard_Limit_Table */
90 00 (0x90h) USHORT usVddciLookupTableOffset; /* points to ATOM_Vega10_Voltage_Lookup_Table */
74 02 (0x274h) USHORT usPCIETableOffset; /* points to ATOM_Vega10_PCIE_Table */
39 01 (0x139h) USHORT usPixclkDependencyTableOffset; /* points to ATOM_Vega10_PIXCLK_Dependency_Table */
0F 01 (0x10Fh) USHORT usDispClkDependencyTableOffset; /* points to ATOM_Vega10_DISPCLK_Dependency_Table */
63 01 (0x163h) USHORT usPhyClkDependencyTableOffset; /* points to ATOM_Vega10_PHYCLK_Dependency_Table */
} ATOM_Vega10_POWERPLAYTABLE;
VEGA PowerPlay has OD limits as:-
Code:
80 A9 03 00 (2400MHz) ULONG ulMaxODEngineClock; /* For Overdrive. */
F0 49 02 00 (1500MHz) ULONG ulMaxODMemoryClock; /* For Overdrive. */
Code:
32 00 (50%) USHORT usPowerControlLimit;
MCLK_Dependency_Table
MclkDependencyTable, min 167MHz HBM max 945MHz, 4 states. Fiji had only 1 HBM state (500MHz), it was possible to modify PowerPlay to have more (video/post in Fiji bios mod).
Code:
typedef struct _ATOM_Vega10_MCLK_Dependency_Table {
01 UCHAR ucRevId;
04 UCHAR ucNumEntries; /* Number of entries. */
3C 41 00 00 (167MHz) ULONG ulMemClk; /* Clock Frequency */
00 UCHAR ucVddInd; /* SOC_VDD index */
00 UCHAR ucVddMemInd; /* MEM_VDD - only non zero for MCLK record */
00 UCHAR ucVddciInd; /* VDDCI = only non zero for MCLK record */ }
50 C3 00 00 (500MHz) ULONG ulMemClk; /* Clock Frequency */
01 UCHAR ucVddInd; /* SOC_VDD index */
00 UCHAR ucVddMemInd; /* MEM_VDD - only non zero for MCLK record */
00 UCHAR ucVddciInd; /* VDDCI = only non zero for MCLK record */ }
80 38 01 00 (800MHz) ULONG ulMemClk; /* Clock Frequency */
02 UCHAR ucVddInd; /* SOC_VDD index */
00 UCHAR ucVddMemInd; /* MEM_VDD - only non zero for MCLK record */
00 UCHAR ucVddciInd; /* VDDCI = only non zero for MCLK record */ }
24 71 01 00 (945MHz) ULONG ulMemClk; /* Clock Frequency */
03 UCHAR ucVddInd; /* SOC_VDD index */
00 UCHAR ucVddMemInd; /* MEM_VDD - only non zero for MCLK record */
00 UCHAR ucVddciInd; /* VDDCI = only non zero for MCLK record */
}ATOM_Vega10_MCLK_Dependency_Record;
Gfxclk_Dependency_Table
GfxclkDependencyTable, min 852MHz max 1600MHz, 8 states.
Code:
typedef struct _ATOM_Vega10_GFXCLK_Dependency_Table {
00 UCHAR ucRevId;
08 UCHAR ucNumEntries; /* Number of entries. */
D0 4C 01 00 (852MHz) ULONG ulClk; /* Clock Frequency */
00 UCHAR ucVddInd; /* SOC_VDD index */
00 80 USHORT usCKSVOffsetandDisable; /* Bits 0~30: Voltage offset for CKS, Bit 31: Disable/enable for the GFXCLK level. */
00 00 USHORT usAVFSOffset; /* AVFS Voltage offset */ }
1C 83 01 00 (991MHz) ULONG ulClk; /* Clock Frequency */
01 UCHAR ucVddInd; /* SOC_VDD index */
00 00 USHORT usCKSVOffsetandDisable; /* Bits 0~30: Voltage offset for CKS, Bit 31: Disable/enable for the GFXCLK level. */
00 00 USHORT usAVFSOffset; /* AVFS Voltage offset */ }
88 BC 01 00 (1138MHz) ULONG ulClk; /* Clock Frequency */
02 UCHAR ucVddInd; /* SOC_VDD index */
00 00 USHORT usCKSVOffsetandDisable; /* Bits 0~30: Voltage offset for CKS, Bit 31: Disable/enable for the GFXCLK level. */
00 00 USHORT usAVFSOffset; /* AVFS Voltage offset */ }
B4 EF 01 00 (1269MHz) ULONG ulClk; /* Clock Frequency */
03 UCHAR ucVddInd; /* SOC_VDD index */
00 00 USHORT usCKSVOffsetandDisable; /* Bits 0~30: Voltage offset for CKS, Bit 31: Disable/enable for the GFXCLK level.*/
00 00 USHORT usAVFSOffset; /* AVFS Voltage offset */ }
90 0E 02 00 (1348MHz) ULONG ulClk; /* Clock Frequency */
04 UCHAR ucVddInd; /* SOC_VDD index */
00 00 USHORT usCKSVOffsetandDisable; /* Bits 0~30: Voltage offset for CKS, Bit 31: Disable/enable for the GFXCLK level.*/
00 00 USHORT usAVFSOffset; /* AVFS Voltage offset */ }
80 32 02 00 (1440MHz) ULONG ulClk; /* Clock Frequency */
05 UCHAR ucVddInd; /* SOC_VDD index */
00 00 USHORT usCKSVOffsetandDisable; /* Bits 0~30: Voltage offset for CKS, Bit 31: Disable/enable for the GFXCLK level.*/
00 00 USHORT usAVFSOffset; /* AVFS Voltage offset */ }
E0 54 02 00 (1528MHz) ULONG ulClk; /* Clock Frequency */
06 UCHAR ucVddInd; /* SOC_VDD index */
00 00 USHORT usCKSVOffsetandDisable; /* Bits 0~30: Voltage offset for CKS, Bit 31: Disable/enable for the GFXCLK level. */
00 00 USHORT usAVFSOffset; /* AVFS Voltage offset */ }
00 71 02 00 (1600MHz) ULONG ulClk; /* Clock Frequency */
07 UCHAR ucVddInd; /* SOC_VDD index */
00 00 USHORT usCKSVOffsetandDisable; /* Bits 0~30: Voltage offset for CKS, Bit 31: Disable/enable for the GFXCLK level. */
00 00 USHORT usAVFSOffset; /* AVFS Voltage offset */
} ATOM_Vega10_GFXCLK_Dependency_Record;
Vddc/Vddmem LookupTable
Code:
7A 00 (0x7Ah) USHORT usVddcLookupTableOffset; /* points to ATOM_Vega10_Voltage_Lookup_Table */
8C 00 (0x8Ch) USHORT usVddmemLookupTableOffset; /* points to ATOM_Vega10_Voltage_Lookup_Table*/
VddmemLookupTable has 1350mV, no idea if this is HBM voltage or something else. Fiji did not have HBM voltage in PowerPlay, nor was it 1.2V, but 1.3V. Not read about HBM2 at all TBH, but would have expected it lower or 1.3V, perhaps AMD needed to give it a bump if this values is indeed that.
Code:
7A 00 (0x7Ah) USHORT usVddcLookupTableOffset; /* points to ATOM_Vega10_Voltage_Lookup_Table */
typedef struct _ATOM_Vega10_Voltage_Lookup_Table {
01 UCHAR ucRevId;
08 UCHAR ucNumEntries; /* Number of entries */
20 03 (800mV) USHORT usVdd; /* Base voltage */
84 03 (900mV) USHORT usVdd; /* Base voltage */
B6 03 (950mV) USHORT usVdd; /* Base voltage */
E8 03 (1000mV) USHORT usVdd; /* Base voltage */
1A 04 (1050mV) USHORT usVdd; /* Base voltage */
4C 04 (1100mV) USHORT usVdd; /* Base voltage */
7E 04 (1150mV) USHORT usVdd; /* Base voltage */
B0 04 (1200mV) USHORT usVdd; /* Base voltage */
8C 00 (0x8Ch) USHORT usVddmemLookupTableOffset; /* points to ATOM_Vega10_Voltage_Lookup_Table */
typedef struct _ATOM_Vega10_Voltage_Lookup_Table {
01 UCHAR ucRevId;
01 UCHAR ucNumEntries; /* Number of entries */
46 05 (1350mV) USHORT usVdd; /* Base voltage */
PowerTune_Table
Ref'ing the Linux info, there are 2 slightly differing setups of PowerTune, one I believe is for the AIO version and the other for AIR version. PowerTune_Table_V2 I believe is for the AIR version.
Code:
typedef struct _ATOM_Vega10_PowerTune_Table {
07 UCHAR ucRevId;
DC 00 (220W) USHORT usSocketPowerLimit;
DC 00 (220W) USHORT usBatteryPowerLimit;
DC 00 (220W) USHORT usSmallPowerLimit;
2C 01 (300A) USHORT usTdcLimit;
00 00 USHORT usEdcLimit;
59 00 (89°C) USHORT usSoftwareShutdownTemp;
69 00 (105°C) USHORT usTemperatureLimitHotSpot;
49 00 (73°C) USHORT usTemperatureLimitLiquid1;
49 00 (73°C) USHORT usTemperatureLimitLiquid2;
5F 00 (95°C) USHORT usTemperatureLimitHBM;
73 00 (115°C) USHORT usTemperatureLimitVrSoc;
73 00 (115°C) USHORT usTemperatureLimitVrMem;
64 00 (100°C) USHORT usTemperatureLimitPlx;
40 00 (64Ω??) USHORT usLoadLineResistance;
90 UCHAR ucLiquid1_I2C_address;
92 UCHAR ucLiquid2_I2C_address;
97 UCHAR ucVr_I2C_address;
60 UCHAR ucPlx_I2C_address;
96 UCHAR ucLiquid_I2C_LineSCL;
00 UCHAR ucLiquid_I2C_LineSDA;
90 UCHAR ucVr_I2C_LineSCL;
55 UCHAR ucVr_I2C_LineSDA;
00 UCHAR ucPlx_I2C_LineSCL;
00 UCHAR ucPlx_I2C_LineSDA;
00 00 USHORT usTemperatureLimitTedge;
} ATOM_Vega10_PowerTune_Table;
typedef struct _ATOM_Vega10_PowerTune_Table_V2 {
07 UCHAR ucRevId;
DC 00 USHORT usSocketPowerLimit;
DC 00 USHORT usBatteryPowerLimit;
DC 00 USHORT usSmallPowerLimit;
2C 01 USHORT usTdcLimit;
00 00 USHORT usEdcLimit;
59 00 USHORT usSoftwareShutdownTemp;
69 00 USHORT usTemperatureLimitHotSpot;
49 00 USHORT usTemperatureLimitLiquid1;
49 00 USHORT usTemperatureLimitLiquid2;
5F 00 USHORT usTemperatureLimitHBM;
73 00 USHORT usTemperatureLimitVrSoc;
73 00 USHORT usTemperatureLimitVrMem;
64 00 USHORT usTemperatureLimitPlx;
40 00 USHORT usLoadLineResistance;
90 UCHAR ucLiquid1_I2C_address;
92 UCHAR ucLiquid2_I2C_address;
97 UCHAR ucLiquid_I2C_Line;
60 UCHAR ucVr_I2C_address;
96 UCHAR ucVr_I2C_Line;
00 UCHAR ucPlx_I2C_address;
90 UCHAR ucPlx_I2C_Line;
55 00 (85°C) USHORT usTemperatureLimitTedge;
} ATOM_Vega10_PowerTune_Table_V2;
Code:
5F 00 (95°C) USHORT usTemperatureLimitHBM;
AFAIK HBM1 should also have had a temperature sensor, as JEDEC PDF highlighted with increased temps HBM should lower performance to reduce temps. No monitoring on Fiji showed this temp, either it was not implemented or not exposed for SW to show.
Testing of PowerPlay registry mods
Intro to PowerPlay registry mod
GPU idle voltage has shifted?
What about lowering idle voltage?
What is HBM voltage in WattMan/OverdriveNTool?
Setting my WattMan profile in PP reg mod
PowerPlay registry takes precedent over VBIOS PowerPlay. As this occurs at OS load some mod values may not work. As they may require to be there at initialization of card. Hopefully as further testing is done we will know which are the ones that do not function. As VEGA has been closed off for VBIOS mod it could also been other restrictions are in place via driver for mods we may do.
In below image GPU-Z shows default clocks as if VBIOS had been modified, only PowerPlay registry mod was used.
When we use OS OC SW we see differing default clocks to OC set.
Warning: Do not change pointers (ie offset location values) in PowerPlay, red line values below image. This will corrupt PowerPlay leading to OS load not occurring. These values are like the directory to sections within PowerPlay.
In below image GPU-Z shows default clocks as if VBIOS had been modified, only PowerPlay registry mod was used.
When we use OS OC SW we see differing default clocks to OC set.
Warning: Do not change pointers (ie offset location values) in PowerPlay, red line values below image. This will corrupt PowerPlay leading to OS load not occurring. These values are like the directory to sections within PowerPlay.
GPU idle voltage has shifted?
A number of us have noticed that with OS OC SW the GPU will not idle at ~<800mV. Why this occurs is due to when we OC using OS SW, "dynamically" lower DPM clocks and mV are affected. This is not an OS OC SW issue but just how driver is IMO.
Some have thought the card is stuck in a higher DPM at idle when we have applied OC via OS SW, I believe it is not. This can be evident from:-
a) GPU frequency at idle.
b) GPU Tach LEDs, which I believe denote active GPU DPM state.
The greater the OC applied in OS by SW, more lower DPMs are affected and voltage increases of these DPMs could be bigger. Why I think this, is due to Hawaii/Fiji both exhibited this. On those GPUs we could take an AIDA 64 GPU registers dump before and after tweaking card in OS and see the changes(currently VEGA this is not supported). When the OC was applied through VBIOS this did not happen, only DPMs that were altered got affected. There are posts with those tests in Hawaii/Fiji bios mod.
I have also applied my usual OC setup via PP mod and then idle is <~800mV. So IMO this is better method of having our OC profile applied. I have also tested restoring driver to factory defaults with OC profile applied to registry and it will still remain. So I also believe when a crash of an app/load on GPU occurs and driver is reset it will use the PP reg mod as defaults.
Below is image of 3 way compare, left is no PP reg mod and no WattMan tweaks, centre is no PP mod but WattMan used for tweaks, right is PP mod and WattMan set to Custom to show the values.
Some have thought the card is stuck in a higher DPM at idle when we have applied OC via OS SW, I believe it is not. This can be evident from:-
a) GPU frequency at idle.
b) GPU Tach LEDs, which I believe denote active GPU DPM state.
The greater the OC applied in OS by SW, more lower DPMs are affected and voltage increases of these DPMs could be bigger. Why I think this, is due to Hawaii/Fiji both exhibited this. On those GPUs we could take an AIDA 64 GPU registers dump before and after tweaking card in OS and see the changes(currently VEGA this is not supported). When the OC was applied through VBIOS this did not happen, only DPMs that were altered got affected. There are posts with those tests in Hawaii/Fiji bios mod.
I have also applied my usual OC setup via PP mod and then idle is <~800mV. So IMO this is better method of having our OC profile applied. I have also tested restoring driver to factory defaults with OC profile applied to registry and it will still remain. So I also believe when a crash of an app/load on GPU occurs and driver is reset it will use the PP reg mod as defaults.
Below is image of 3 way compare, left is no PP reg mod and no WattMan tweaks, centre is no PP mod but WattMan used for tweaks, right is PP mod and WattMan set to Custom to show the values.
What about lowering idle voltage?
So far in PP reg mod testing this has not been possible. It seems as if GPU is in a idle DPM that we have no control over from OS OC SW or PP reg mod. Even if I set DPM 0 as 700mV and DPM 1 as 750mV I see the same idle voltages as stock card (~<800mV). There is an exception to this, currently I believe placing that test info here would cause confusion.
What is HBM voltage in WattMan/OverdriveNTool?
In the PowerPlay there is only 1 HBM voltage 1.25V for V56 and 1.35V for V64/FE. So HBM mV in WattMan is not correct.
Example of HBM voltage in PowerPlay
Above table is the HBM voltage table. Below is entry it contains for my card/VBIOS.
Trying to fix an issue I had with HBM being stuck at ~500MHz with not GPU load, after ~30min+ normal use, I discovered what HBM mV in WattMan/OverdriveNTool is, link to post (read info there carefully so below will make sense).
Each HBM DPM has an association with SOCCLK, the SOCCLK I believe is linking to a GPU state.
So what happens is WattMan/OverdriveNTool picks up the HBM DPM, sees the link from it to SOCCLK/GPUCLK and shows a value of mV for that GPU DPM. If you read the linked post earlier you will have seen that HBM and SOC clock tables have no voltages, just link via ID number, etc.
For example if you change GPU DPM 5 voltage in PowerPlay using reg mod you will see that value in WattMan (OverdriveNTool HBM P3). Change GPU DPM 0 in PowerPlay reg mod and you will see HBM P0/1 mV change in OverdriveNTool. Change GPU DPM 2 to see HBM P2 mV change.
I currently think when we change HBM mV in WattMan and HBM P3 in OverdriveNTool it causes detachment of HBM highest clock from relevant GPU DPM. Thus we see lowered mV as we lower GPU state 6 in these apps. I believe both these apps need updating as to not cause confusion.
Example of HBM voltage in PowerPlay
Code:
8C 00 (0x8Ch) USHORT usVddmemLookupTableOffset; /* points to ATOM_Vega10_Voltage_Lookup_Table */
Code:
typedef struct _ATOM_Vega10_Voltage_Lookup_Table {
01 UCHAR ucRevId;
01 UCHAR ucNumEntries; /* Number of entries */
ATOM_Vega10_Voltage_Lookup_Record entries[1]; /* Dynamically allocate entries */
} ATOM_Vega10_Voltage_Lookup_Table;
typedef struct _ATOM_Vega10_Voltage_Lookup_Record {
46 05 (1350mV) USHORT usVdd; /* Base voltage */
} ATOM_Vega10_Voltage_Lookup_Record;
Trying to fix an issue I had with HBM being stuck at ~500MHz with not GPU load, after ~30min+ normal use, I discovered what HBM mV in WattMan/OverdriveNTool is, link to post (read info there carefully so below will make sense).
Each HBM DPM has an association with SOCCLK, the SOCCLK I believe is linking to a GPU state.
So what happens is WattMan/OverdriveNTool picks up the HBM DPM, sees the link from it to SOCCLK/GPUCLK and shows a value of mV for that GPU DPM. If you read the linked post earlier you will have seen that HBM and SOC clock tables have no voltages, just link via ID number, etc.
For example if you change GPU DPM 5 voltage in PowerPlay using reg mod you will see that value in WattMan (OverdriveNTool HBM P3). Change GPU DPM 0 in PowerPlay reg mod and you will see HBM P0/1 mV change in OverdriveNTool. Change GPU DPM 2 to see HBM P2 mV change.
I currently think when we change HBM mV in WattMan and HBM P3 in OverdriveNTool it causes detachment of HBM highest clock from relevant GPU DPM. Thus we see lowered mV as we lower GPU state 6 in these apps. I believe both these apps need updating as to not cause confusion.
Setting my WattMan profile in PP reg mod
So my usual tweaked OC profile in WattMan is:-
DPM6: 1557MHz 975mV
DPM7: 1642MHz 1275mV
HBM: 1100MHz
PowerLimit: 38%
Now for PP reg mod to apply it is not necessary for WattMan to be placed in Custom mode on slider. The PP reg mod will act as Balanced profile and defaults for Custom. But the mV set in GPU DPM via reg mod will not apply until you change to "Custom", move voltage to manual and hit "Apply".
I will replace image above or add another with mods done, for now I believe this suffices to show what to do.
Notes:-
i) Any clocks must have 00 on the end in PowerPlay reg editor when making as what used in WattMan (ie 1642MHz = 164200).
ii) PowerLimit values replaced in Power reg editor and when registry mod applied, will become stock value for 0%. Therefore increasing PL using slider in OS OC SW will increase PL +% for those values. For my OC TDC increase in PowerPlay reg is not necessary, I only need to increase the 3x TDP values. So I can not confirm yet if TDC value increase has an affect. It would be assumed as VRM controller would have an OCP value this would still apply. When OCP on VRM controller is triggered on past AMD GPUs I played with, card will shutdown and rig require reset.
iii) In the past DPM clocks acted as ceiling for a state change IMO. Below is an example for Dead Space capped FPS load, GPU was using ~1095MHz this was below DPM 3 MHz (1138MHz default in my case). So if I wished to lower mV used, I changed DPM 3 mV in PowerPlay.
When driver/GPU was using ACG/AVFS state/mode (Dead Space uncapped FPS load), I observed GPU clock of ~1100MHz and peaking higher at times. Now this clock would mean it should have used a non ACG/AVFS state/mode, but it does not.
So the range of ACG/AVFS states is currently unknown. The only way to tell is the fluctuating aspect of GPU voltage in monitoring and somewhat value used.
So my current hypothesis is driver/GPU is assessing app/load using GPU and determining if it uses a non ACG/AVFS state/mode or not. This could make some testing aspects/setup of profiles harder than on previous gen AMD GPUs.
Below image left is Dead Space uncapped FPS, centre is capped to 140, right is capped to 140 but DPM 3 edited for lower voltage.
HML files:-
DS_compare.zip 35k .zip file
Notes for HMLs:
i) The 1st HML created (uncapped), the higher "bouncy" GPU clock section is menu section. I had not used this game since OS install so was setting options up. The middle flatter section with some peaks is in game section.
ii) The 3rd HML where I have lowered DPM 3 mV by ~50mV (ie set 950mV), GPU/driver placed HBM in 800MHz state. When on same "profile" I used a 3D load which placed GPU in ACG/AVFS DPMs (5/6/7) I gained 1100MHz again, so I was not experiencing HBM MHz bug.
DPM6: 1557MHz 975mV
DPM7: 1642MHz 1275mV
HBM: 1100MHz
PowerLimit: 38%
Now for PP reg mod to apply it is not necessary for WattMan to be placed in Custom mode on slider. The PP reg mod will act as Balanced profile and defaults for Custom. But the mV set in GPU DPM via reg mod will not apply until you change to "Custom", move voltage to manual and hit "Apply".
I will replace image above or add another with mods done, for now I believe this suffices to show what to do.
Notes:-
i) Any clocks must have 00 on the end in PowerPlay reg editor when making as what used in WattMan (ie 1642MHz = 164200).
ii) PowerLimit values replaced in Power reg editor and when registry mod applied, will become stock value for 0%. Therefore increasing PL using slider in OS OC SW will increase PL +% for those values. For my OC TDC increase in PowerPlay reg is not necessary, I only need to increase the 3x TDP values. So I can not confirm yet if TDC value increase has an affect. It would be assumed as VRM controller would have an OCP value this would still apply. When OCP on VRM controller is triggered on past AMD GPUs I played with, card will shutdown and rig require reset.
iii) In the past DPM clocks acted as ceiling for a state change IMO. Below is an example for Dead Space capped FPS load, GPU was using ~1095MHz this was below DPM 3 MHz (1138MHz default in my case). So if I wished to lower mV used, I changed DPM 3 mV in PowerPlay.
When driver/GPU was using ACG/AVFS state/mode (Dead Space uncapped FPS load), I observed GPU clock of ~1100MHz and peaking higher at times. Now this clock would mean it should have used a non ACG/AVFS state/mode, but it does not.
So the range of ACG/AVFS states is currently unknown. The only way to tell is the fluctuating aspect of GPU voltage in monitoring and somewhat value used.
So my current hypothesis is driver/GPU is assessing app/load using GPU and determining if it uses a non ACG/AVFS state/mode or not. This could make some testing aspects/setup of profiles harder than on previous gen AMD GPUs.
Below image left is Dead Space uncapped FPS, centre is capped to 140, right is capped to 140 but DPM 3 edited for lower voltage.
HML files:-
DS_compare.zip 35k .zip file
Notes for HMLs:
i) The 1st HML created (uncapped), the higher "bouncy" GPU clock section is menu section. I had not used this game since OS install so was setting options up. The middle flatter section with some peaks is in game section.
ii) The 3rd HML where I have lowered DPM 3 mV by ~50mV (ie set 950mV), GPU/driver placed HBM in 800MHz state. When on same "profile" I used a 3D load which placed GPU in ACG/AVFS DPMs (5/6/7) I gained 1100MHz again, so I was not experiencing HBM MHz bug.
Updating UEFI/GOP module in VBIOS
Will be looking add other sections and VBIOS info soon as and when required . So do check OP for updates, usually I will bump thread with a post .