Radeon VII Overclocking & Undervolting

[Gurdi]

Nö. Jedenfalls nicht über die Limits in der PowerPlay Table. Die ist identisch zur v105, und falls diese nun nicht ausgehebelt wurden.. Hab ich ja schon erzählt..

Ich kann mal eben schaun welche Tables genau verändert wurden.. dauert einen Augenblick.

Ja deine Aussage kam mir dabei auch in den Sinn, aber irgendwo ist die Leistungsaufnahme gedrosselt worden, das kann ich klar in den Messungen sehen.

 

[hellm]

Veränderungen gibt nur bei diesen Tables:

Data Tables:
(FirmwareInfo)
(SupportedDevicesInfo)
(MC_InitParameter/AdjustARB_SEQ)
(VRAM_Info)

Bei den Command Tables gab es gar keine Änderungen.
Etwas mit dem Fan könnte ich noch über die Firmware Info table erklären, das ist für Software: "Shared by various SW components". Supported Devices Info seit R600 nicht mehr genutzt, und zu MC_Init ist mir ebenso unbekannt, klingt aber nach Memory.

Ich weiß nicht genau ob ich die aktuellen Versionen erwischt habe (müsst ich jetzt genau im BIOS nachsehn..), aber das ist was ich zu den Data Tables finden konnte:

Firmware Table

Spoiler

typedef struct _ATOM_FIRMWARE_INFO_V2_2
{
  ATOM_COMMON_TABLE_HEADER        sHeader; 
  ULONG                           ulFirmwareRevision;
  ULONG                           ulDefaultEngineClock;       //In 10Khz unit
  ULONG                           ulDefaultMemoryClock;       //In 10Khz unit
  ULONG                           ulSPLL_OutputFreq;          //In 10Khz unit  
  ULONG                           ulGPUPLL_OutputFreq;        //In 10Khz unit
  ULONG                           ulReserved1;                //Was ulMaxEngineClockPLL_Output; //In 10Khz unit*
  ULONG                           ulReserved2;                //Was ulMaxMemoryClockPLL_Output; //In 10Khz unit*
  ULONG                           ulMaxPixelClockPLL_Output;  //In 10Khz unit
  ULONG                           ulBinaryAlteredInfo;        //Was ulASICMaxEngineClock  ?
  ULONG                           ulDefaultDispEngineClkFreq; //In 10Khz unit. This is the frequency before DCDTO, corresponding to usBootUpVDDCVoltage.          
  UCHAR                           ucReserved3;                //Was ucASICMaxTemperature;
  UCHAR                           ucMinAllowedBL_Level;
  USHORT                          usBootUpVDDCVoltage;        //In MV unit
  USHORT                          usLcdMinPixelClockPLL_Output; // In MHz unit
  USHORT                          usLcdMaxPixelClockPLL_Output; // In MHz unit
  ULONG                           ulReserved4;                //Was ulAsicMaximumVoltage
  ULONG                           ulMinPixelClockPLL_Output;  //In 10Khz unit
  UCHAR                           ucRemoteDisplayConfig;
  UCHAR                           ucReserved5[3];             //Was usMinEngineClockPLL_Input and usMaxEngineClockPLL_Input
  ULONG                           ulReserved6;                //Was usMinEngineClockPLL_Output and usMinMemoryClockPLL_Input
  ULONG                           ulReserved7;                //Was usMaxMemoryClockPLL_Input and usMinMemoryClockPLL_Output
  USHORT                          usReserved11;               //Was usMaxPixelClock;  //In 10Khz unit, Max.  Pclk used only for DAC
  USHORT                          usMinPixelClockPLL_Input;   //In 10Khz unit
  USHORT                          usMaxPixelClockPLL_Input;   //In 10Khz unit
  USHORT                          usBootUpVDDCIVoltage;       //In unit of mv; Was usMinPixelClockPLL_Output;
  ATOM_FIRMWARE_CAPABILITY_ACCESS usFirmwareCapability;
  USHORT                          usCoreReferenceClock;       //In 10Khz unit    
  USHORT                          usMemoryReferenceClock;     //In 10Khz unit    
  USHORT                          usUniphyDPModeExtClkFreq;   //In 10Khz unit, if it is 0, In DP Mode Uniphy Input clock from internal PPLL, otherwise Input clock from external Spread clock
  UCHAR                           ucMemoryModule_ID;          //Indicate what is the board design
  UCHAR                           ucReserved9[3];
  USHORT                          usBootUpMVDDCVoltage;       //In unit of mv; Was usMinPixelClockPLL_Output;
  USHORT                          usReserved12;
  ULONG                           ulReserved10[3];            // New added comparing to previous version
}ATOM_FIRMWARE_INFO_V2_2;

bei MC_InitParameter handelt es sich tatsächlich um etwas das den Speicher betrifft:

Spoiler

typedef struct _ATOM_MC_INIT_PARAM_TABLE
{ 
  ATOM_COMMON_TABLE_HEADER        sHeader;
  USHORT                                            usAdjustARB_SEQDataOffset;
  USHORT                                            usMCInitMemTypeTblOffset;
  USHORT                                            usMCInitCommonTblOffset;
  USHORT                                            usMCInitPowerDownTblOffset;
    ULONG                                                ulARB_SEQDataBuf[32];
    ATOM_INIT_REG_BLOCK                    asMCInitMemType;
    ATOM_INIT_REG_BLOCK                    asMCInitCommon;
}ATOM_MC_INIT_PARAM_TABLE;

Auch nix Interessantes in Supported Devices:

Spoiler

typedef struct _ATOM_SUPPORTED_DEVICES_INFO_2d1
{ 
  ATOM_COMMON_TABLE_HEADER      sHeader;
  USHORT                        usDeviceSupport;
  ATOM_CONNECTOR_INFO_I2C       asConnInfo[ATOM_MAX_SUPPORTED_DEVICE];
  ATOM_CONNECTOR_INC_SRC_BITMAP asIntSrcInfo[ATOM_MAX_SUPPORTED_DEVICE];
}ATOM_SUPPORTED_DEVICES_INFO_2d1;

Und in der Vram Info findet sich alles was sich um den verwendeten Speicher dreht, wie Hersteller, Timings, etc.

Spoiler

typedef struct _ATOM_VRAM_INFO_HEADER_V2_1
{
  ATOM_COMMON_TABLE_HEADER   sHeader;
  USHORT                     usMemAdjustTblOffset;                                                     // offset of ATOM_INIT_REG_BLOCK structure for memory vendor specific MC adjust setting
  USHORT                     usMemClkPatchTblOffset;                                                 //    offset of ATOM_INIT_REG_BLOCK structure for memory clock specific MC setting
  USHORT                     usPerBytePresetOffset;                          // offset of ATOM_INIT_REG_BLOCK structure for Per Byte Offset Preset Settings
  USHORT                     usReserved[3];
  UCHAR                      ucNumOfVRAMModule;                              // indicate number of VRAM module
  UCHAR                      ucMemoryClkPatchTblVer;                         // version of memory AC timing register list
  UCHAR                      ucVramModuleVer;                                // indicate ATOM_VRAM_MODUE version
  UCHAR                      ucReserved; 
  ATOM_VRAM_MODULE_V7             aVramInfo[ATOM_MAX_NUMBER_OF_VRAM_MODULE];      // just for allocation, real number of blocks is in ucNumOfVRAMModule;
}ATOM_VRAM_INFO_HEADER_V2_1;

typedef struct _ATOM_VRAM_MODULE_V7
{
// Design Specific Values
  ULONG      ulChannelMapCfg;                    // mmMC_SHARED_CHREMAP
  USHORT  usModuleSize;                     // Size of ATOM_VRAM_MODULE_V7
  USHORT  usPrivateReserved;                // MC_ARB_RAMCFG (includes NOOFBANK,NOOFRANKS,NOOFROWS,NOOFCOLS)
  USHORT  usEnableChannels;                 // bit vector which indicate which channels are enabled
  UCHAR   ucExtMemoryID;                    // Current memory module ID
  UCHAR   ucMemoryType;                     // MEM_TYPE_DDR2/DDR3/GDDR3/GDDR5
  UCHAR   ucChannelNum;                     // Number of mem. channels supported in this module
  UCHAR   ucChannelWidth;                   // CHANNEL_16BIT/CHANNEL_32BIT/CHANNEL_64BIT
  UCHAR   ucDensity;                        // _8Mx32, _16Mx32, _16Mx16, _32Mx16
  UCHAR      ucReserve;                        // Former container for Mx_FLAGS like DBI_AC_MODE_ENABLE_ASIC for GDDR4. Not used now.
  UCHAR      ucMisc;                           // RANK_OF_THISMEMORY etc.
  UCHAR      ucVREFI;                          // Not used.
  UCHAR   ucNPL_RT;                         // Round trip delay (MC_SEQ_CAS_TIMING [28:24]:TCL=CL+NPL_RT-2). Always 2.
  UCHAR      ucPreamble;                       // [7:4] Write Preamble, [3:0] Read Preamble
  UCHAR   ucMemorySize;                     // Total memory size in unit of 16MB for CONFIG_MEMSIZE - bit[23:0] zeros
  USHORT  usSEQSettingOffset;
  UCHAR   ucReserved;
// Memory Module specific values
  USHORT  usEMRS2Value;                     // EMRS2/MR2 Value. 
  USHORT  usEMRS3Value;                     // EMRS3/MR3 Value.
  UCHAR   ucMemoryVenderID;                 // [7:4] Revision, [3:0] Vendor code
  UCHAR      ucRefreshRateFactor;              // [1:0]=RefreshFactor (00=8ms, 01=16ms, 10=32ms,11=64ms)
  UCHAR      ucFIFODepth;                      // FIFO depth can be detected during vendor detection, here is hardcoded per memory
  UCHAR   ucCDR_Bandwidth;                  // [0:3]=Read CDR bandwidth, [4:7] - Write CDR Bandwidth
  char    strMemPNString[20];               // part number end with '0'. 
}ATOM_VRAM_MODULE_V7;

..also für den geringeren Verbrauch wird es andere Gründe geben. Ich tippe sehr auf den Speicher, irgendwas in diesem Zusammenhang, denn dort sind die Veränderungen.

update:
MC_Init.. Memory Controller.. wie konnt ich das übersehn.. . Und der frisst auch bisl mehr, sitzt auf der GPU und so.. VRAM Info ist Timings und HBM selbst.

 

[RX480]

Wäre dann interessant, ob beim Speicher-OCen sich was geändert hat.

 

[BrandWolle]

Mir ist das BIOS Update gelungen mit der enthaltenen Anwendung seitens AMD.

Das erste was mir aufgefallen ist, die Lüfterkurve ist überhaupt nicht mehr sprunghaft. Sie ist jetzt absolut "smooth" und gleichmäßig ansteigend -mit Standardeinstellung.
Hab das jetzt beim Superposition Benchmark gemerkt. Wie wenn es eine komplett neue Karte wäre.

Was sich aber bei mir geändert hat ist die Grundspannung für den Takt:

Vorher: 1801/1046mV
Jetzt: 1801/1051mV

Wie sieht es bei den anderen aus? Hattet ihr vorher höhere Grundspannung anliegen oder jetzt nach dem Update?

Update: Das springen des Taktes zwischen Standardtakt und Boosttakt ist sogut wie eliminiert worden. Das selbe beim Speichertakt.
Mir scheint auch das die TJ etwas gesunken ist im Vergleich zu vorher. Aber UV sollte trotzdem noch gemacht werden!

 

[gaussmath]

@hellm: Die Datenstrukturen/Structs sind das eine, aber wie werden die Objekte definiert, initialisiert? Gibt es dort Unterschiede?

 

[RX480]

update:
MC_Init.. Memory Controller.. wie konnt ich das übersehn.. . Und der frisst auch bisl mehr, sitzt auf der GPU und so.. VRAM Info ist Timings und HBM selbst.

Klingt gut! Der Soc war der Übeltäter. Erstaunlich, wie schnell AMD es Besser macht.
(AMD sollte vllt. mal neue Hardware an willige Betatester HIER verteilen. Dann gehts auch schneller mit Feedback)

 

[hellm]

@hellm: Die Datenstrukturen/Structs sind das eine, aber wie werden die Objekte definiert, initialisiert? Gibt es dort Unterschiede?

Keine Objekte, das ist C.
Spaß beiseite, das ist wirklich alles was geändert wurde. Die Bezeichnungen sind doch recht eindeutig, und die Data Tables sind eben so strukturiert, ATOMBIOS nennt sich das.

Bei den ersten extrem OC Versuchen von CarbonFire hat er auch festgestellt das mit höherer Vcore/Taktrate der HBM etwas niedriger getaktet werden musste, ums noch stabil zu bekommen. Wir haben das mit einer höheren SoC Spannungen bekämpft, AMD hat nun offensichtlich am Memory Controller und dem HBM gedreht.
Am Ende zeigt die Karte nun eben ein derartiges Verhalten. Ich könnte nun noch mehr Zeit darauf verwenden, dann würden wir genau wissen welche Bytes verändert wurden. Wird aber weiterhin nix anderes rauskommen, Änderung der Software-Schnittstelle fürn Fan, sowie Tables für HBM und Speichercontroller GPU.

 

[RX480]

@gaussmath
Du hast doch immer so hohe Temps an der Backplate.
Hier ein Video von Igor zur Konkurrenz, aber eigentlich selbes Problem:
(Er empfiehlt nur bei den Spawas ein Pad zur Backplate; Damit ist genau definiert, Was die Backplate kühlen soll.)
YouTube

 

[Gurdi]

Keine Objekte, das ist C.
Spaß beiseite, das ist wirklich alles was geändert wurde. Die Bezeichnungen sind doch recht eindeutig, und die Data Tables sind eben so strukturiert, ATOMBIOS nennt sich das.

Bei den ersten extrem OC Versuchen von CarbonFire hat er auch festgestellt das mit höherer Vcore/Taktrate der HBM etwas niedriger getaktet werden musste, ums noch stabil zu bekommen. Wir haben das mit einer höheren SoC Spannungen bekämpft, AMD hat nun offensichtlich am Memory Controller und dem HBM gedreht.
Am Ende zeigt die Karte nun eben ein derartiges Verhalten. Ich könnte nun noch mehr Zeit darauf verwenden, dann würden wir genau wissen welche Bytes verändert wurden. Wird aber weiterhin nix anderes rauskommen, Änderung der Software-Schnittstelle fürn Fan, sowie Tables für HBM und Speichercontroller GPU.

Das erklärt die paar Watt die mir nun fehlen. Die gehen jetzt via PCI Express weil wahrscheinlich HBM und SOC via PCI Express gespeist werden.

 

[BrandWolle]

Ich wollte nicht nochmals meinen Beitrag editieren, sorry dafür.

Aber das BIOS hat deutliche Verbesserungen im Superposition gemacht bezüglich der Taktraten.

In 4k optimiert sind es bei 2000/1200 bei 1127mV jetzt 8449 zu 8265 Punkten.

Das ist meiner Meinung nach ein extremer Sprung in die richtige Richtung.

@hellm @gurdi

Glaubt ihr das da noch Verbesserungen auf Stockkühler noch möglich sind durch BIOS oder Treiber?

 

[gaussmath]

Eigentlich ist die Backplate jetzt normal warm würde ich sagen. Man kann dran fassen und den Finger länger auch an den wärmsten Stellen belassen ohne Verbrennungsempfinden.

Ich brauche Kabelmanagement!!

 

[Gurdi]

Ich wollte nicht nochmals meinen Beitrag editieren, sorry dafür.

Aber das BIOS hat deutliche Verbesserungen im Superposition gemacht bezüglich der Taktraten.

In 4k optimiert sind es bei 2000/1200 bei 1127mV jetzt 8449 zu 8265 Punkten.

Das ist meiner Meinung nach ein extremer Sprung in die richtige Richtung.

@hellm @gurdi

Glaubt ihr das da noch Verbesserungen auf Stockkühler noch möglich sind durch BIOS oder Treiber?

Ja auf jeden Fall. Der Treiber ist aktuell ein großes Problem, der macht teils nur Unsinn und setzt keine Boosttable vernünftig um.

 

[JSXShadow]

Da ist man mal ein paar Tage nicht da, dann gibt es direkt ein neues BIOS?! Was ist so Eure Meinung dazu, auf jeden Fall draufhauen, oder warten? Nehme mal an, dann muss man alle Settings nochmal testen. Juckt mir in den Fingern...aber ich denke ich warte bis zum nächsten Treiber-Release und geh das dann zusammen an. Sonst fang ich direkt nochmal an...falls ich die Geduld hab

PS: So viel zum Thema, dass kein Spiel mehr als 8GB auslastet. Hab in letzter Zeit bissl FFXV gezockt mit 4k Texturen...12-13GB VRAM werden belegt nach ung. einer Stunde Spielzeit Da geht doch was!

 

[Gurdi]

Da ist man mal ein paar Tage nicht da, dann gibt es direkt ein neues BIOS?! Was ist so Eure Meinung dazu, auf jeden Fall draufhauen, oder warten? Nehme mal an, dann muss man alle Settings nochmal testen. Juckt mir in den Fingern...aber ich denke ich warte bis zum nächsten Treiber-Release und geh das dann zusammen an. Sonst fang ich direkt nochmal an...falls ich die Geduld hab

PS: So viel zum Thema, dass kein Spiel mehr als 8GB auslastet. Hab in letzter Zeit bissl FFXV gezockt mit 4k Texturen...12-13GB VRAM werden belegt nach ung. einer Stunde Spielzeit Da geht doch was!

Drauf machen. Wirkt keine Wunder, ist aber besser und mit dem Link von Hellm hast du den Topaktuellen ATI Flash.

 

[JSXShadow]

OKi! Dann geht der heute Abend gleich drauf. Wenn sich das Verhalten eigentlich immer verbessert, dann sollten meine Settings ja trotzdem erstmal laufen, vlt noch ein wenig effizienter. Dann man ich direkt mal nen FSUltra heute, update, dann nochmal mit gleichen Settings. Bin mal gespannt

Meinst du die Reg-Mod geht dann noch, oder sollte ich die nicht mehr verwenden, bzw. hat hellm hier schon eine neuere?

Achso, bald sind die 14 Tage um..AMD sollte dann den non-Beta Treiber releasen. Schätze mal so am 27.-28.02. würde ja in deren Schedule passen.

 

[Gurdi]

OKi! Dann geht der heute Abend gleich drauf. Wenn sich das Verhalten eigentlich immer verbessert, dann sollten meine Settings ja trotzdem erstmal laufen, vlt noch ein wenig effizienter. Dann man ich direkt mal nen FSUltra heute, update, dann nochmal mit gleichen Settings. Bin mal gespannt

Meinst du die Reg-Mod geht dann noch, oder sollte ich die nicht mehr verwenden, bzw. hat hellm hier schon eine neuere?

Achso, bald sind die 14 Tage um..AMD sollte dann den non-Beta Treiber releasen. Schätze mal so am 27.-28.02. würde ja in deren Schedule passen.

Die PPT´s funzen weiterhin.

 

[RX480]

Glaubt ihr das da noch Verbesserungen auf Stockkühler noch möglich sind durch BIOS oder Treiber?

Eigentlich reicht jetzt der "gaussmod" vollkommen aus, wenn man net zu dolle OCen will.(1850..1950/1150..1200 für 24/7)
Pack mal 2 gute Lüfter drauf. (+PWM-Adapter+Y-Kabel)
Und wenn man soundso gute Temps(mit bios v1.06) hat, dann ist auch das Pad richtig gut drauf und der Ref.-Lüfter optimal angezogen.
(würde Daher auch net mit den U-Scheiben/Federringen hantieren- das Pad ist eigentlich ausreichend zum Ausgleich)

 

[JSXShadow]

Federringe usw haben bei mir zum Beispiel gar nichts gebracht. Die bringen wohl nur was, wenn jemand bei der Assembly murks gemacht hat und es generell nicht ordentlich angezogen war.

Aber ja, kann jedem nur empfehlen, Shroud ab, 2x A12x25 von Noctua drauf (wenn mans wirklich leise will) und gut ist. 65€ kosten mit Adapter, 20 Minuten arbeit maximal, Lautstärke...kann man gar nicht vergleichen. Unter Vollast wie gesagt ung. die Lautstärke der Stock-Lüfter um die 50%, also wesentlich effizienter.

Hab aber auch schon gesehen, dass es auch kühler geht. Wenn man Lüfter mit mehr satic Pressure nimmt dann wirds vlt nicht leiser, aber dann doch ein wenig kühler. Headroom ist mit dem Stock-Kühler auch noch vorhanden. Das erkläre ich mir damit, dass die 2x 140mm Fans die noch extra von unten Luft ansaugen, nahe der VII, die Temps erneut um 5-7° verbessert haben.

PS: Man, kann das Ergebnis-Video von Steve von Gamers Nexus kaum erwarten..hoffe der hat ne Kack-Karte und/oder testet keine 3DMark Benches...mag Platz 1 bleiben vom Graphics Score...auch CarbonFire's 150 Punkte mehr in FireStrike muss ich bald mal richten! Mit nem clean-Windows, optimierten Diensten/Treibersettings und vlt noch ein paar MHz mehr, sollten die 34k drinnen sein...aber so viel Arbeit

 

[BrandWolle]

Federringe usw haben bei mir zum Beispiel gar nichts gebracht. Die bringen wohl nur was, wenn jemand bei der Assembly murks gemacht hat und es generell nicht ordentlich angezogen war.

Aber ja, kann jedem nur empfehlen, Shroud ab, 2x A12x25 von Noctua drauf (wenn mans wirklich leise will) und gut ist. 65€ kosten mit Adapter, 20 Minuten arbeit maximal, Lautstärke...kann man gar nicht vergleichen. Unter Vollast wie gesagt ung. die Lautstärke der Stock-Lüfter um die 50%, also wesentlich effizienter.

Hab aber auch schon gesehen, dass es auch kühler geht. Wenn man Lüfter mit mehr satic Pressure nimmt dann wirds vlt nicht leiser, aber dann doch ein wenig kühler. Headroom ist mit dem Stock-Kühler auch noch vorhanden. Das erkläre ich mir damit, dass die 2x 140mm Fans die noch extra von unten Luft ansaugen, nahe der VII, die Temps erneut um 5-7° verbessert haben.

PS: Man, kann das Ergebnis-Video von Steve von Gamers Nexus kaum erwarten..hoffe der hat ne Kack-Karte und/oder testet keine 3DMark Benches...mag Platz 1 bleiben vom Graphics Score...auch CarbonFire's 150 Punkte mehr in FireStrike muss ich bald mal richten! Mit nem clean-Windows, optimierten Diensten/Treibersettings und vlt noch ein paar MHz mehr, sollten die 34k drinnen sein...aber so viel Arbeit

Deine über 8100 Grafikpunkte haben mich angespornt im FSUltra. Die optimierte Luftkühlung hat da wohl viel gebracht
Mit Wasserkühlung schlage ich zurück und hoffe unter die Top 3 mit der Seven zu kommen was Grafikpunkte betrifft

 

[JSXShadow]

Deine über 8100 Grafikpunkte haben mich angespornt im FSUltra. Die optimierte Luftkühlung hat da wohl viel gebracht ��
Mit Wasserkühlung schlage ich zurück und hoffe unter die Top 3 mit der Seven zu kommen was Grafikpunkte betrifft��

Witzigerweise habe ich mit meinem Lüftermod noch keinen Extrem-OC Benchmark versucht. Das war alles noch mti Stock-Kühler
Ja ich muss mal wieder ran, besonders da mein Gehäuse noch schön neu und frisch ist. Final Fantasy XV spielt sich aber gerade so gut

Ach naja, was solls, wenn ich morgen aus dem Tagesdienst komme setze ich mich nochmal ran. Nach dem BIOS-Update und mit max Lüfter kann ich vlt mein Max-OC setting stabiler betreiben bzw. mit einer stabileren Taktrate. Vielleicht reicht das schon für mehr score! Overall bringt aber mein neues Gehäuse + der Lüfter-Mod, wenn alles auf 100% läuft knapp 13° Verbesserung als zuvor. Hoffe, dass ich damit die Benches stabiler durchbekomme, aber wir werden sehen. Platz 1 kann ich generell von den Gesamtpunkten nicht erreichen, da nur ein 9900k auf 4.8GHz xDD "nur", daher guck ich eigentlich nur auf den graphics score

PS: Achso, eh ich es vergesse. Wenn du in diese BEreiche kommst musst du stark mit dem HBM aufpassen. Der wird da immer empfindlicher, wahrscheinlich den Temps geschuldet. Seltsamerweise machen dann aber schon 5 MHz auf dem HBM ne Menge Punkte aus (ja! Einstellige Verbesserungen sind eine Menge! )