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

I'm also observing all of this, here and at the Luxx. And I honestly don't know what all these details. If I understood what all these "More" do and cause, then I would include it in my tutorial, or write it again here with pictures. But mentally it all left me behind at some point in the spring. And no matter how stupid, or evil, or whatever it sounds, I don't expect that a good manual will be created elsewhere - that was the original motivation for my tutorial, to make everything about "Navi 2X vs. MPT" understandable get together.

In my understanding, Hellm "simply" collects everything that is in the AMD drivers and gives us that as controllable functions in the MPT and Veii was started to reveal the last secrets of the drivers including the bios of the cards. The current intermediate status is this More page, which in my opinion no longer helps normal OCers, but only for the very curious - because all the efforts have so far not resulted in big new OC high scores. Veii is still (trying) to find something, but in the last few weeks his communications have not been too enthusiastic either.
Thinking of the Pareto principle, I think we're through. The last 1-3% performance now has to be scraped out with 200-300% effort, and it is uncertain whether it can even work.
Thanks for sharing practically my thoughts )
It just so happened for the unfortunate reasons that I get my hands on Navi2x basically at the end of its product cycle, and thus being curious enough to dig into undocumented features I personally feel it's like "too-lazy-cause-too-late" .
Anyway, some points to complete my thoughts:
  • most (95%) of the pp table entries for the gfx10 are no secret and has pretty clear designation (at least @me and anyone who tried to search for the info and not just ask for it in forums)
  • fully agree without knowing (I mean literally, not just a guesswork) what a certain parameter is responsible for the best case outcome is a waste of time
  • if I was the mpt developer i'd start from the SMU metrics and SVI2 telemetry monitoring soft first, to be able to cover as much of dynamically changing operating points or sensors as the firmware provides. The list of available metrics:
    CurrClock[GFXCLK]
    CurrClock[SOCCLK]
    CurrClock[UCLK]
    CurrClock[FCLK]
    CurrClock[DCLK0]
    CurrClock[VCLK1]
    CurrClock[DCLK0]
    CurrClock[VCLK1]
    CurrClock[DCEFCLK]
    CurrClock[DISPCLK]
    CurrClock [PIXCLK]
    CurrClock[PHYCLK]
    CurrClock[DTBCLK]

    AverageGfxclkFrequencyPreDs
    AverageGfxclkFrequencyPostDs
    AverageFclkFrequencyPreDs
    AverageFclkFrequencyPostDs
    AverageUclkFrequencyPreDs
    AverageUclkFrequencyPostDs

    AverageGfxActivity
    AverageUclkActivity
    CurrSocVoltageOffset
    CurrGfxVoltageOffset
    CurrMemVidOffset
    AverageSocketPower

    TemperatureEdge
    TemperatureHotspot
    TemperatureMem
    TemperatureVrGfx
    TemperatureVrMem0
    TemperatureVrMem1
    TemperatureVrSoc
    TemperatureLiquid0
    TemperatureLiquid1
    TemperaturePlx

    AccCnt
    ThrottlingPercentage[TEMP_EDGE]
    ThrottlingPercentage[TEMP_HOTSPOT]
    ThrottlingPercentage[TEMP_MEM]
    ThrottlingPercentage[TEMP_VR_GFX]
    ThrottlingPercentage[TEMP_VR_MEM0]
    ThrottlingPercentage[TEMP_VR_MEM1]
    ThrottlingPercentage[TEMP_VR_SOC]
    ThrottlingPercentage[TEMP_LIQUID0]
    ThrottlingPercentage[TEMP_LIQUID1]
    ThrottlingPercentage[TEMP_PLX]
    ThrottlingPercentage[TDC_GFX]
    ThrottlingPercentage[TDC_SOC]
    ThrottlingPercentage[PPT0]
    ThrottlingPercentage[PPT1]
    ThrottlingPercentage[PPT2]
    ThrottlingPercentage[PPT3]
    ThrottlingPercentage[FIT]
    ThrottlingPercentage[PPM]
    ThrottlingPercentage[APCC]

    LinkDpmLevel
    CurrFanPwm
    CurrFanSpeed

    EnergyAccumulator
    AverageVclk0Frequency
    AverageDclk0Frequency
    AverageVclk1Frequency
    AverageDclk1Frequency
    VcnUsagePercentage0
    VcnUsagePercentage1
    PcieRate
    PcieWidth
    AverageGfxclkFrequencyTarget

    ApuSTAPMSmartShiftLimit
    AverageApuSocketPower
    ApuSTAPMLimit
  • in addition to (and followed from) the above, I'd base the tuning utility partly on a direct SMC calls which are well described in a amdgpu driver sources, due to its direct nature and therefore no need to restart driver to show and observe the effect immediately. For this, we'd probably need to just modify the existing kernel driver (inpoutx64) for the PCI device r/w access and memcopy of the tables content to/from user/kernel space, but I'm not sure of that. Of course not excluding "legacy" tinkering with the PowerPLay and OverDrive (and a bunch of other) tables modification to bootup.
PS: It's funny how many people are surprised by the lack of documentation on amd internals, when everyone who's at least slightly familiar with this topic should see the obvious reasons for this
 
Zuletzt bearbeitet :
wirdlangsam.jpg
Wird langsam was. Grün geht in die richtige richtung.
Peak waren 2626MHz, mit dem normalen modell ist da eher bei 2570 schluss.
 
aber in den letzten Wochen waren seine Mitteilungen auch nicht mehr zu enthustiastisch.
Das stimmt :)
Es ist mühsam & einsam~~

Ich nahm mir mal ne laaange Pause vom rumwühlen, die letzten 2 Monate // abseits von Navi
Besonders weil ich konstant auf die 110° hocke mit der Karte.
Gestern eben (2+6+2h) für die dämliche Kurve und gut ist sie immer noch nicht. (6h failure and not even bios posts)
Wir brauchen einen Visualizer und eine core-jump Automatisierung.
(on start increase frequency in steps of 7+6+6+6+7+6+6+6+7 and so on, to measure current curve)

Bei mir ist Ruhe im LUXX, weil ich letzten Monat in nem private collegial NonDistribute lag.
Auf OCN ist ebenfalls ruhe. Es heißt nicht "es bringt nichts", sondern "ich hab die Schnauze voll nur alleine research zu pushen"
Nun geht es Aufwärts, das freut mich :)
SOC, FCLK, MCLK sind alle limitiert und messbar. Es bringt viel. Im Sinne von 150mV reduction "viel". Substrate-Strain Reduction == Higher Clock.

Aber vieles ist noch hinter verschlossenen Türen.
Selbst wenn RDNA 3 rauskommt, die Methodik bleibt die selbe, bloß umso komplexer.
Nur über 400W komme ich nun mal nicht und bin auf andere Tester abhängig~
Im 36° Sommer zu benchmarken war auch nicht das ware, nun mal abseits von den "wortwörtlich doppelten" Stromkosten. Ich hab auch noch ein leben um den erhöhten Blödsinn irgendwie zu stabilisieren & versuche von hier wegzuziehen
Aber nein, eher weil ich busy bin ~ nicht weil ich das Interesse verlor. Es gibt noch seeehr viel zu tun, ich komme bloß nicht hinterher.

Einfach abwarten, im frühesten Zeitraum wäre alles interesannte erst am Ende dieses Monats.
Vieles vom rumgeteste ist underground, ansonnsten müsste ich es komplett sein lassen und garnicht darüber reden.
Einfach abwarten , ne einfach weiterforschen. Auf andere nur zu warten ist auch nicht so das wahre (y)
 
@ApolloX von meiner Perspektive, geht es momentan hervorragend voran. Nun mit up and downs natürlich
Was aber fehle:
~ man muss Lordkag (OCN?) kontaktieren für genauere GOP und ROM placement instructions
~ man muss The Stilt kontaktieren für genauere LeakageID Auslese Möglichkeiten und etwas Hilfe zu PSM Werten (BTC included)
~ man braucht einen Developer für 2 Projekte. Navi PerPart Quadratic Automation & by-step frequency increase via SMU.
Um ne V/F Curve zu bauen & ggf einen Visual Plotter für Quadratic Math
~ Wir brauchen korrektes tracking aller Werte via PCI MUTEX (SMU) nicht über Wattman oder HWInfo SMU calls. Diese sind zu langsam. ~ PJVol ??
~ RSA lock außerhalb GOP in ROM muss Fallen, um überhaupt etwas intereesanntes machen zu können, oder AMD muss endlich die DeviceID V & F Limiters von den Drivern entfernen.

Was die letzten 3 Monate erreicht wurde:
~ VBFlash windows-lock fiel, ich hab einen exploit der auf RDNA3's Launch wartet. ~ ich
~ DFLL müsste soweit fertig sein, nur man muss damit Arbeiten können ~ sibradzic + 1usmus & gepusht von mir
~ Memory Timings fielen sowie AMDs encryption ~ Wolf
~ On-Boot Rom check fiel, aber InROM RSA Lock stört und hindert noch den rebrand ~ ich
~ SOC (FCLK, MCLK, SOCCLK) throttle gefunden aber noch zu unstabil ab 92° ~ ich
~ Driver controll zugriff durch AMDs API ~ R.B.R.T & Hellm

Es gibt noch einiges oben zu tun :)
Fällt das ROM signing, dann fällt auch der Rebrand lock.
Dementsprechend würde sogar das "locked CU" limit fallen & custom memory timings funktionieren.
Der OS/Registry Teil ist fein. Der Firmware Teil ist noch ein offenes Buch.
Das Einzige was wir nicht können, sind die lästigen Driver limits zu umgehen, außer mit einem Elmor-EVC über nicht trackbare offsets.

MemOC müsste ebenso auf allen anderen Karten nun gehen mit dem ROM-Spoofing, den es ist eher eine SOC Spannungs Sache, welches FLCK & MCLK limitiert
Soweit hiervon mal

EDIT:
"Problematisch" ist nur, dass ich die Karte bis etwa Oktober, anfang November hätte. Maximal
Ich habe noch den Boutique-Build fertigzustellen, DDR5 + Zen4 ~ und dann stoppt auch der Research zu dem Thema von mir.
Ich komme mit allem nicht hinterher. Somit fühlt es sich "nach Ruhe" an.
 
Zuletzt bearbeitet :
erstes feedback: kann's sein, dass bei PerPartDroopVsetGfxDfll nichts übernommen wird? oder muss irgendwo an anderer stelle noch etwas gesetzt werden?
wenn ich dort meine uv settings ändern / eintragen will (4: 1032, 5: 1087), ist nach erneutem öffnen der more curve settings alles beim alten an dieser stelle.
ich nutz das lc bios einer 6950 auf einer ref 6900xt und per part piece wise linear ist gesetzt (y)
 
Bei mir funktioniert das.
 
wenn ihr mögt, könnt ihr mit dieser registry datei übrigens im alten context menu (ich nutz unter win 11 das alte, das neue ist mir zu umständlich; das alte ist auch im neuen unter "erweitert" o.ä. zu erreichen, da findet ihr die einträge dann) das MoreClockTool und das MorePowerTool eintragen. vllt. müsst ihr noch die pfade anpassen, bei mir wird der standard pfad aus dem installer genutzt. nachdem ich seit erscheinen des MCT nur noch die minimal driver installation nutze, aber trotzdem per context menu die takte etc ändern möchte, hab ich mir die mal in die registry eingetragen.

im reg file ist auch noch ein "open admin cmd prompt here" eintrag, den brauch ich auch öfter; wer den ned braucht, kann ihn ja 'rauslöschen (y) ansonsten befinden sich somit nur diese drei einträge darin: MCT, MPT und admin cmd.

@RedF tatsache?? in den fünf feldern die mit pfeil markiert sind (ich nutz schnell das alte bereits hier hochgeladene file) kannst du was ändern und es wird übernommen? bei mir nicht :oops: hast du da noch an anderer stelle etwas geändert?
mist... oder auch gut... aber mist für mich halt :D
Screenshot 2022-09-18 075358.png
 

Anhänge

  • more_context.zip
    548 Bytes · Aufrufe : 12
@RedF tatsache?? in den fünf feldern die mit pfeil markiert sind (ich nutz schnell das alte bereits hier hochgeladene file) kannst du was ändern und es wird übernommen? bei mir nicht :oops: hast du da noch an anderer stelle etwas geändert?
mist... oder auch gut... aber mist für mich halt :D
Anhang anzeigen 20514
Ja unten auf OK, dann write SPPT und es ist drinne. Hat auch auswirkungen.

Stimmt ja, du hast eine zu frühe version : )
 
Ich glaube ich habe den Treiber seit gestern zuviel geärgert, jetzt läuft garnichts mehr durch -_-
 
Danke für die Reg-Datei, interessante Idee. Ist die Aktivierung des alten Kontextmenüs in deiner Änderung bereits enthalten, wie sie hier beschrieben wird?

nee, die änderung ist dort nicht enthalten, die müsste noch durchgeführt werden wenn gewünscht. das geschah schon vor ein paar monaten, das neue ging auf dauer einfach mal gar nicht...

Redownload, es gab nen bug fix
Ja unten auf OK, dann write SPPT und es ist drinne. Hat auch auswirkungen.

Stimmt ja, du hast eine zu frühe version : )

dann update ich mal (y) danke!

edit: funktioniert nun! :)
 
Danke. Ich werde die Kontexteinträge wohl auf dem Win-10-Test- und Benchsystem einpflegen. Unter Win 11 sind Icons zentral auf der Taskleiste genauso komfortabel.

Was anderes: Curve. Einige wie @seadersn scheinen sich bereits ernsthaft damit zu beschäftigen, während ich im Moment noch davorsitze wie ein Schimpanse an der Schreibmaschine. Ich erwarte keine ausführlichen Erläuterungen (oder gar ein Tutorial von @Veii, für das er sich viel kostbare Zeit nehmen müsste und ich es dann doch nicht verstehe).

Aber so ein paar Ansatzpunkte, wo und wie loslegen: das wäre schön. Ich finde z. B. die Charts von @RedF interessant. Wenn ich wüsste, wie ich so was erzeuge, würde ich für ein erstes grundlegendes Verständnis der Curve-Thematik damit beginnen, meine existierenden Kurven (stock, OCUV, OCOV) abzubilden. Denn an diesen Zahlensalat (links mein 6900 Ref-Bios, rechts das von RedF gepostete 6950er) würde ich mich zwar rantrauen, lack of courage is not the issue. Aber ich wüsste schlicht nicht, was ich tue. Es sei denn, jemand sagt mir in kurzen Sätzen, mach erst dies, dann dies und dann das, hat diese, jene und celle Wirkung.

8.png 8_6950.png

tltr: Eine Beschreibung erster Basis-Steps und/oder eine Anleitung zur grafischen Curve-Darstellung wäre toll!

Edit: @RedF hat den Weg zum Graphen anscheinend im Discord-Server OCDB beschrieben, wie ich gerade sehe. Ist das zu viel für hier? Kommt die CSV-Datei aus HWiNFO? Welche 3D-Anwendung wird aufgezeichnet?
 
Zuletzt bearbeitet :
excelimport5.jpgexcelimport6.jpgexcelimport7.jpgexcelimport8.jpgExcelChart9.jpg
 
ExcelChart10.jpgExcelChart11.jpgExcelChart12.jpg
 
Zuletzt bearbeitet :
Manchmal erkennt Excel die werte auch gleich als zahlen und manchmal die erste zeile als überschrift, da fallen dann einige schritte weg.
 
Oben Unten