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

Ja ich dachte mir es ist eine Seriennummer (Ziemlich falsch gedacht anscheinend)
Macht ja, nix, muss man nicht wissen. Die Nummern hinter der AMD Vendor ID und Device ID sind übrigens die IDs vom Boardpartner. Auch keine Seriennummer.
 
@Veii: Das hier scheint ganz gut zu funktionieren. Niedrige anliegende GPU-Spannung, niedriger Verbrauch, 2660 MHz default wie gewünscht.

24140_Curve_Veii6.png

Zum Vergleich noch mal das Setting vorher auf Basis deiner Vorschläge:

24150_Curve_Veii1.png

Die fehlenden 200-300 GP zu 22.11.2 krieg ich mit dem aktuellen Treiber nicht mehr rein. Der Bencher in mir hat daran zu kauen, aber imerhin: Der Verlust scheint Spiele aber nicht zu betreffen, siehe hier.

Es liegt nicht zufällig irgendwo ein gespooftes Bios mit 2719 MHz Grundtakt bei dir rum, oder? 😇
 
Zuletzt bearbeitet :
Gibt es einen besonderen Grund bis 300W tgp die GFX zu cappen, aber bei 350W mit dem speziell angepassten AVFS Override net mehr?
... eigentlich ist doch zw. der eff.Spannung 1041mV bei 350W und den 1175mV(=eff. 1115mV bei 400W) jede Menge Luft für Spielereien

Will jetzt aber Niemanden zu zeitraubenden Aktivitäten animieren, ... vllt. hat ja Jemand schon einschlägige Erfahrungen.(x)
(Devcom hatte net die AVFS benutzt, aber gecappt auf 1143mV)


(x) falls das Cappen sich ungünstig aufs Offset MPT zu WM auswirkt, wäre das z.Bsp. ein Grund bei den original 1175mV zu bleiben
Devcom meint, das in so nem Bereich dann die minGFX im MPT wichtiger wird, um große Offset zu fahren (mit altem Treiber)
minGFX so ca. 963...987 je nach Wattbereich (Mantiz hatte zuletzt sogar 987 mit der XTXH)
 
Zuletzt bearbeitet :
@Veii: Um in Time Spy wieder auf einen ordentlichen Score zu kommen, startete ich AVFS "from scratch" und schreckte auch nicht vor GPU-OC zurück. Das kam bisher dabei raus (bitte GPU-MHz beachten und AVFS Override):

2732_24604_Curve_neu4.png

GFX default wäre 2655 MHz. Was sagst du zu den AVFS-Werten? Überraschend, dass das bisher (auch in Spielebenchmarks und einer Stunde "Uncharted - Legacy of Thieves") stabil ist? Oder würdest du das erwarten?

Interessanterweise kommt es wiederholt vor, dass obige MPT-Settings mit 2732 und 2725 MHz durch TS gehen, 2719 und 2713 aber hängenbleiben. Die Curve ist schon ein seltsames Wesen.

Die Spiele-Fps sind übrigens hervorragend mit diesen Einstellungen. Kein Wunder, denn der TS-Verlust von 22.11.2 auf 23.2.1 betrifft sie ja nicht. In absoluten Zahlen sparsam ist das Setting natürlich nicht.

Edit
Noch eine altbekannte Sache, diesmal in Richtung @hellm: Wann immer ich das nach dem Windows-Start teste, bestätigt sich: Delete SPPT, restart64 und dann das gewünschte gespeicherte MPT-Setting aufrufen und anwenden ist schneller als nach dem Start mit demselben Setting einfach loszugamen oder zu -benchen. 2% Fps-Unterschied, schätze ich. Irgend eine Idee, warum?

Edit 2
@RX480: Der Offset existiert auch mit AVFS-Tweaking, nur nicht mehr offensichtlich, weil sich das innerhalb der Curve abspielt.

Im Beispiel oben könnte ich GFX max auf 1150 statt 1175 absenken, ohne Wirkung allerdings. Würde ich 1125 versuchen, ginge das nicht durch, weil ein bestimmter Max-Takt eine bestimmte Max-Spannung benötigt und dabei ein "Respektabstand" zwischen Treiber-V und anliegender V gewahrt bleiben muss (siehe Vorschaugrafik unten zu Teil 2 des Radeon-6000-Effizienz-Guides in der nächsten PCGH, "klassisches" UV). Dieser Abstand würde in den TS-Settings oben (2732 MHz, max 1079 mV) bei 1125 MPT-mV unterschritten; ein Abbruch des Benchmarks wäre die Folge.

Screenshot 2023-02-13 180843.png

Bei AVFS-Einsatz bleiben alle Voltages in MCT und MPT auf Default, auch weil der Überblick von Ursache und Wirkung sonst leicht verlorengehen kann. AVFS regelt intern und unsichtbar, das macht es im Vergleich zum einfachen Undervolting auch so schon kompliziert genug.

So weit mein Verständnis davon.
 
Zuletzt bearbeitet :
Der Taktwechsel könnte u.U. gerade im Wechselbereich Kurve 4 zu Kurve 5 liegen und somit ab 1725 die Kurve 5 nutzen, die ein anderes "c" hat.
1713 ist gerade noch Kurve 4 ? ... bei ner sparsamen GPU@h2o
(ob dann noch der andere eff.Takt nach Restart ne Rolle spielt, who knows)

Was passiert wenn man bei Kurve 4 den Wert "c" von Kurve "5" nimmt?
(wäre Das stabiler)
 
Zuletzt bearbeitet :
Ich bearbeite die Kurve ausschließlich per AVFS Override, dachte, das sei inzwischen klar geworden. Deine Frage dazu habe ich beantwortet, gern geschehen. Wenn dich interessiert, was in den einzelnen Abschnitten 1 bis 5 und a bis c der Curve geschieht, freuen wir uns auf deine Tests und Berichte.
 
Danke!

Die per part Kurven gibts doch nur für den den 6x50er Refresh (und Dich extra).
Sonst würden wohl mehr Leute mit ner normalen 6x00 dazu posten.
(Das jetzt ala redF bei mir reinzuhieven ist mir zu unübersichtlich, gerade weil meine nonXT gaaanz andere Werte nimmt als die 6800XT )
 
Danke!

Die per part Kurven gibts doch nur für den den 6x50er Refresh (und Dich extra).
Sonst würden wohl mehr Leute mit ner normalen 6x00 dazu posten.
(Das jetzt ala redF bei mir reinzuhieven ist mir zu unübersichtlich, gerade weil meine nonXT gaaanz andere Werte nimmt als die 6800XT )
Die unterschiede sind gering, würde eine 6950 Kurve nehmen und anpassen.
 
Die std kurve passt schon sehr gut.
 
Noch eine altbekannte Sache, diesmal in Richtung @hellm: Wann immer ich das nach dem Windows-Start teste, bestätigt sich: Delete SPPT, restart64 und dann das gewünschte gespeicherte MPT-Setting aufrufen und anwenden ist schneller als nach dem Start mit demselben Setting einfach loszugamen oder zu -benchen. 2% Fps-Unterschied, schätze ich. Irgend eine Idee, warum?
Also gehen wir mal davon aus, dass es nicht an der SPPT liegt. Die überschreibt die PPTable wie immer, ob nach Treiberreset oder Neustart, soviel wissen wir. Also werden wir mit dieser Annahme wohl richtig liegen.
Damit läuft in beiden Szenarios die Karte mit exakt denselben Specs. Bleibt noch der Rest vom System.

Meine Antwort bleibt also dieselbe, irgendetwas fährt restart64 herunter, was normalerweise aktiv wäre. Software, keine Änderung an der Hardware. Sonst fällt mir keine Theorie ein, die deine Beobachtungen hinreichend erklären könnte. Ich seh mir das bei Gelegenheit mal mit meiner 6600 an, bis dahin kannst du gerne Sensordaten sammeln.
 
irgendetwas fährt restart64 herunter, was normalerweise aktiv wäre.
Das klingt zunächst plausibel, und tatsächlich scheinen auf dem Gaming-System die Hotkeys von AMD Adrenalin nach restart64 nicht mehr zu funktionieren, solange die Oberfläche danach nicht manuell aufgerufen wurde; das will ich aber noch mal verifizieren. * Allerdings reduzieren Treiberprozesse nicht die Gamingleistung um 1–3 %, aktive Aufnahmefunktionen in Bereitschaft mal ausgenommen.

Außerdem: Derselbe Effekt tritt auch auf dem Benchsystem auf. Dort ist aber keine Adrenalin-Oberfläche installiert, sondern nur der nackte Treiber über den Windows-Gerätemanager. Die einzigen zusätzlichen AMD-Dienste und Prozesse sind Crash Defender und External Events, und die sind auch nach restart64 noch aktiv.

Was die These darüber hinaus in Frage stellt und das MPT wieder ins Spiel bringt: restart64 allein löst die Mehr-Fps (bzw. Beseitigung der Minder-Fps) nicht aus. Delete SPPT muss dazu ausgeführt werden. Dann restart, dann Load, dann restart. Die klassische H-Methode eben.

Ich seh mir das bei Gelegenheit mal mit meiner 6600 an
Ja bitte. :)

bis dahin kannst du gerne Sensordaten sammeln.
Da gibt es nichts Auffälliges. Geringfügig schwächere Leistung geht mit geringfügig niedrigeren HWiNFO-Werten einher.

Edit:
"Entwarnung" @Veii: Der nur schwer nachzuvollziehende niedrige c-Wert von nur 0.000500 bei einem Takt von 2732 MHz aus #3.326 lässt sich in der aktuellen Nachtbench-Session nicht mehr stabil reproduzieren. Jetzt sind 0.007500 nötig, bei entsprechend höherer Voltage und Leistungsaufnahme. Das passt sicher besser ins Bild. Setzt den Default-Takt übrigens auf 2644 herunter.

Zwei Sessions, zwei Ergebnisse. Ehrlich, Leute: Wer ein Leben hat, sollte sich mit diesem Quatsch nicht rumschlagen. ;)

Edit 2:
* gemacht: Da hab ich mich getäuscht. Die Hotkeys ALT+R und ALT+Z zum Aufruf der Oberfläche funktionieren auch nach restart64 noch.
 
Zuletzt bearbeitet :
Versuche B leicht wegzuarbeiten, den es verschiebt die Kurve nur nach links
Dies hat mich übrigens einige Teststunden lang auf die falsche Fährte geführt und mich an meinem Verständnis für die Curve zweifeln lassen. Denn "wegarbeiten" lässt sich als "in Richtung null bringen" verstehen. Der Negativwert muss aber so weit es geht erhöht werden. Das hast du sicher auch gemeint.

Screenshot 2023-02-23 022745.png

Dass Time Spy um 1 % schlechter scored, ist nicht zu ändern. Spiele gehen aber gut: Komme bis auf Haaresbreite wieder an die Verbrauchs- und Fps-Werte von 22.11.2 ran, inzwischen mit 23.2.2. Danke für deinen Input!
 
Zuletzt bearbeitet :
Whenever I test this after the Windows start, it confirms: Delete SPPT, restart64 and then call up the desired saved MPT setting and apply it is faster than after starting with the same setting
ASIC init procedure could (and most likely do) differ in these two cases. Some settings in the SPPT just didn't apply at boot (either due to the bug or intentionally, for example BIOS pp_table has higher priority for some settings). Though in my case the difference between the TS scores is always around 1.5-1.6%

@hellm
I'm afraid there's no way to track this unless you know how to log smu metrics table v2/v3.
Anyway, I know of at least one reproducible scenario where soft power play settings "stuck" at boot and ignored.

PS: to illustrate the matter these two TS runs were made with absolutely identical Overdrive and SPPT settings and the results are 100% reproducible
GPU @ default 255W power limit, adrenaline 23.2.2
 

Anhänge

  • ts1.png
    ts1.png
    590,4 KB · Aufrufe : 43
  • ts2.png
    ts2.png
    582,7 KB · Aufrufe : 35
  • overdrive.png
    overdrive.png
    12 KB · Aufrufe : 57
Zuletzt bearbeitet :
From my early and limited experience with the 23.2.2 driver, this may help pass TS with the previously stable VddGfx offset:
 

Anhänge

  • 23-2-2-curve-adj.png
    23-2-2-curve-adj.png
    39,1 KB · Aufrufe : 63
Moin zusammen.

Anscheinend hab ich ein Brett vorm Kopf, aber das BIOS meiner RX6800 lässt sich nicht in den RBE laden.

Ich bekomme immer die Fehlermeldung "not supportet"

Was mach ich denn falsch?!
 
Moin zusammen.

Anscheinend hab ich ein Brett vorm Kopf, aber das BIOS meiner RX6800 lässt sich nicht in den RBE laden.

Ich bekomme immer die Fehlermeldung "not supportet"

Was mach ich denn falsch?!
Wie hast du es denn extrahiert?
Xaphirs antwort passt : )
 
Oben Unten