Overclock.net banner

Preliminary view of AMD VEGA Bios

483K views 1K replies 241 participants last post by  homeless dorito 
#1 · (Edited)
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.

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:

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. */
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.

Code:
32 00 (50%)                  USHORT usPowerControlLimit;
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).

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*/
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.

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;
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.

Testing of PowerPlay registry mods

Intro to PowerPlay registry 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.


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.


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

Code:
  8C 00 (0x8Ch)                USHORT usVddmemLookupTableOffset;          /* points to ATOM_Vega10_Voltage_Lookup_Table */
Above table is the HBM voltage table. Below is entry it contains for my card/VBIOS.


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.

Updating UEFI/GOP module in VBIOS

Use Lordkag's UEFI GOPupd tool :) , link.



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 :) .
 

Attachments

See less See more
1 11
#627 ·
@poisson21

+rep, thanks for data
smile.gif
.

Does having SOCCLK lower than HBM clock incurr performance loss compared with when insync?
 
#629 ·
@rednow

GPU/Driver can not read/utilise VBIOS from another switch position until the switch is flipped physically. Each VBIOS only has one PowerPlay. So far only PowerPlay has SOCCLK.

If SOCCLK is rising past highest value on latest driver once HBM clock exceeds it, then "we" can only assume driver has an implementation to do this.

If SOCCLK is not rising past highest value on prior driver to latest once HBM clock exceeds it, then "we" can only assume it lacks implementation that latest has.

The driver can overide VBIOS parameters, it has been seen in the past. An example is when Polaris got released. The reference PCB VRM bias was adjusted to load PCI-E plugs powered VRM more than PCI-E slot.

Anyhow I will stop posing queries now, ~24hrs or so I should have card and then will test with old/new driver and see what goes on.
 
#630 ·
Quote:
Originally Posted by gupsterg View Post

@rednow

GPU/Driver can not read/utilise VBIOS from another switch position until the switch is flipped physically. Each VBIOS only has one PowerPlay. So far only PowerPlay has SOCCLK.

If SOCCLK is rising past highest value on latest driver once HBM clock exceeds it, then "we" can only assume driver has an implementation to do this.

If SOCCLK is not rising past highest value on prior driver to latest once HBM clock exceeds it, then "we" can only assume it lacks implementation that latest has.

The driver can overide VBIOS parameters, it has been seen in the past. An example is when Polaris got released. The reference PCB VRM bias was adjusted to load PCI-E plugs powered VRM more than PCI-E slot.

Anyhow I will stop posing queries now, ~24hrs or so I should have card and then will test with old/new driver and see what goes on.
I don't mean another bios but another value from the same bios in different byte offset.
Just look to this post http://www.overclock.net/t/1633446/preliminary-view-of-amd-vega-bios/610#post_26410448
 
#632 ·
Quote:
Originally Posted by gupsterg View Post

@majestynl

Thanks for data, +rep
smile.gif
.

SOCCLK is not currently modified in any SoftPowerPlay reg file in thread by hellm.

If you go past 1100MHz on new driver without SOCCLK mod what happens?

I have my VEGA Block, card is in transit
biggrin.gif
, hopefully with me tomorrow.
Yeap
thumb.gif
, it looks liks the soc grows with the HBM! 1200Mhz on SOC now
smile.gif


I set the HBM on 1140mhz. Superposition bench went fine.
HBM and Hotspot Temps are a bit higher, slightly better score in SP
Im going to try to give it more Power with PP.. will update

 
#633 ·
Quote:
Originally Posted by rednow View Post

I guess it is near 180watt.
It's not optimal settings for ETH. For ETH you could use 1220/1150@820mV having the same 46.2mhs and 150watt power consumption.
That is impressive. I tried the PP mod to set my voltage to 925mv, but didn't see a big big power drop with my Kilowatt meter. I'm not sure if my downvolting is even applying. The only way I can reduce power consumption is to use the power limit slider. Using that I can get the card down to 210 watts @ 1050mhz core/1025mhz HBM and I get 41.2 MH/s. Trying to go any lower than 19% on the power slider and the HBM downclocks to 550MHz.
 
#634 ·
@majestynl

Thank for info
smile.gif
. Nice result that beats result on my MSI GTX 1080 EK X which boosted to 1965MHz for that bench "out of box" as on water/nvidia boost 3.0 tech, so very nice IMO.

@rednow

What I did to check what star2k has highlighted in green bold text (ie c0,d4,01,00,07).

i) I copied his posted reg file and paste in notepad.
ii) Used "Replace" command to change , to space, then removed / , then made hex continuous to copy and paste in HXD. I have attached saved file from HXD below.

star2k_SoftPowerPlay.zip 1k .zip file


iii) Next I matched the PowerPlay to RX VEGA 64 AIR VBIOS Switch 1 linked in OP, supplied by Sicness.

What we see is PowerLimit is 60% in Star2k files vs 50% in VBIOS, when you do a compare of PowerPlay you will see 3Ch vs 32h.

There are no other differences between Star2k softpowerplay and the Sicness supplied V64 AIR PowerPlay

Next what is c0,d4,01,00,07?

These hex values are residing in:-

Code:

Code:
43 01        (143h) USHORT usDispClkDependencyTableOffset;     /* points to ATOM_Vega10_DISPCLK_Dependency_Table */
Code:

Code:
typedef struct _ATOM_Vega10_POWERPLAYTABLE {
        struct atom_common_table_header sHeader;
00              UCHAR  ucTableRevision;
5C 00           USHORT usTableSize;                        /* the size of header structure */
E1 06 00 00     ULONG  ulGoldenPPID;                       /* PPGen use only */
EE 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     ULONG  ulMaxODEngineClock;                 /* For Overdrive. */
F0 49 02 00     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   USHORT usStateArrayOffset;                 /* points to ATOM_Vega10_State_Array */
4F 02   USHORT usFanTableOffset;                   /* points to ATOM_Vega10_Fan_Table */
46 02   USHORT usThermalControllerOffset;          /* points to ATOM_Vega10_Thermal_Controller */
94 00   USHORT usSocclkDependencyTableOffset;      /* points to ATOM_Vega10_SOCCLK_Dependency_Table */
9E 01   USHORT usMclkDependencyTableOffset;        /* points to ATOM_Vega10_MCLK_Dependency_Table */
BE 00   USHORT usGfxclkDependencyTableOffset;      /* points to ATOM_Vega10_GFXCLK_Dependency_Table */
28 01   USHORT usDcefclkDependencyTableOffset;     /* points to ATOM_Vega10_DCEFCLK_Dependency_Table */
7A 00   USHORT usVddcLookupTableOffset;            /* points to ATOM_Vega10_Voltage_Lookup_Table */
8C 00   USHORT usVddmemLookupTableOffset;          /* points to ATOM_Vega10_Voltage_Lookup_Table */
BC 01   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 */
72 02   USHORT usPowerTuneTableOffset;             /* points to ATOM_Vega10_PowerTune_Table */
00 00   USHORT usHardLimitTableOffset;             /* points to ATOM_Vega10_Hard_Limit_Table */
90 00   USHORT usVddciLookupTableOffset;           /* points to ATOM_Vega10_Voltage_Lookup_Table */
A8 02   USHORT usPCIETableOffset;                  /* points to ATOM_Vega10_PCIE_Table */
6D 01   USHORT usPixclkDependencyTableOffset;      /* points to ATOM_Vega10_PIXCLK_Dependency_Table */
43 01   USHORT usDispClkDependencyTableOffset;     /* points to ATOM_Vega10_DISPCLK_Dependency_Table */
97 01   USHORT usPhyClkDependencyTableOffset;      /* points to ATOM_Vega10_PHYCLK_Dependency_Table */

So we go to offset 143 of PowerPlay in HXD and we can see the table has 8 entries (2nd byte 08h).

The last entry is what Star2k has highlighted and is 1200MHz.

I do not know if he has made an error in compare of PP before new driver and after.



Anyhow my post is not to upset/discredit anyone, just is as info
grouphug.gif
.
 

Attachments

#635 ·
Oh ! I'm a celibrity
biggrin.gif


I dont compare the new with the old, I say, the new driver use this line, not the older.
If you look in older post, you will see someone say "change the 1107mhz of P-State SoC to 1207mhz". And it works, but now, everyone can raise over 1100mhz for the HBM without this modification...

I find something interesting.

If you copy every record of SoC P-State "OC" in "Stock", HBM don't go at 800mhz on Power save profil.

Another thing, in reg, you can see the reference of State frequency for the HBM, and after, the reference P-State for voltage of memory controller, the interesting thing is, if you set like that :

80,38,01,00,01,00,00,24,71,01,00,02

The HBM doesn't down clock at 800mhz if your gpu don't go under 1084mhz.

At the first time, i belive, this reference it's just for voltage of memory controller, but it's more directive that i think...

Anyone can give me the extract of reg for this driver please ?
 
#636 ·
Quote:
Originally Posted by gupsterg View Post

@majestynl

Thank for info
smile.gif
. Nice result that beats result on my MSI GTX 1080 EK X which boosted to 1965MHz for that bench "out of box" as on water/nvidia boost 3.0 tech, so very nice IMO.
Your welcome!
thumb.gif
I also ad the PP on top of it. And working flawless
smile.gif
Went to 1190Mhz on HBM. Still no issues
smile.gif
Only HBM temps are rising but yeah thats normal...
Curious if we can go higher with the soc in PP and so on with HBM
wink.gif
biggrin.gif


Screenie last SP Bench:


Edit1: Firestrike Graphics went 26K +
biggrin.gif




@gupsterg Looking forward for your tests/results tomorrow
wink.gif


@Nuke33 YW !
 
#644 ·
I hate not keeping up with threads like this one. So much great info shared and I can't keep track of who came up with what.

Anyway 17.10.2 does do 1100+ HBM clock for me. For my very rough testing with GPU-z render test(if you tried to run it at 1100+ on the previous driver it would crash) I can pass 1210. 1220 artifacts for me. I tried setting the SOC clock to 1250 in the PPT. That didn't help. I also tried 1.38V HBM2 voltage with the 1250 SOC clock and stability did not improve. Looks like the weak link is the SOC itself. I think bumping it from 0.9V to maybe 0.95V could help however I can't get a datasheet for the chips making up the VRM for it(and as far as I can tell these voltages aren't accessible through software at all). Also I'm pretty sure that overvolting the SOC is a quick way to kill the SOC since most memory controllers are pretty fragile when it comes to raising their operating voltage.

I do plan to run my V56 on LN2 pretty soon. Hopefully the SOC scale with cold and I can test HBM clocks in excess of 1210.
 
#649 ·
Quote:
Originally Posted by Star2k View Post

I have try at 1205mhz for a few second but with the stock blower, i can't bench like this. I don't know where is the limit...
Will give it a try myself in a moment
smile.gif

Quote:
Originally Posted by buildzoid View Post

I hate not keeping up with threads like this one. So much great info shared and I can't keep track of who came up with what.

Anyway 17.10.2 does do 1100+ HBM clock for me. For my very rough testing with GPU-z render test(if you tried to run it at 1100+ on the previous driver it would crash) I can pass 1210. 1220 artifacts for me. I tried setting the SOC clock to 1250 in the PPT. That didn't help. I also tried 1.38V HBM2 voltage with the 1250 SOC clock and stability did not improve. Looks like the weak link is the SOC itself. I think bumping it from 0.9V to maybe 0.95V could help however I can't get a datasheet for the chips making up the VRM for it(and as far as I can tell these voltages aren't accessible through software at all). Also I'm pretty sure that overvolting the SOC is a quick way to kill the SOC since most memory controllers are pretty fragile when it comes to raising their operating voltage.

I do plan to run my V56 on LN2 pretty soon. Hopefully the SOC scale with cold and I can test HBM clocks in excess of 1210.
@gupsterg and @Nuke33 Found it. Day after we got a new driver
smile.gif

Quote:
Originally Posted by Dolk View Post

Anyone creating a new info post for 17.10.2 PP table update?
Like said before, pp table from hellm still works with new driver. Soc increases inline with HBM!
 
#651 ·
Quote:
Originally Posted by Dolk View Post

Anyone creating a new info post for 17.10.2 PP table update?
Since SoftPowerPlay is a copy of the PowerPlayInfo table found in the BIOS, it does not need any updates. Unless you would flash another BIOS, but you can even use other PP tables.
And they are all still the same, no BIOS Update from AMD where PP table was changed.
 
This is an older thread, you may not receive a response, and could be reviving an old thread. Please consider creating a new thread.
Top