Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Grade in der Pause gelesen, es geht dabei darum das mit Kernel 6.9 endlich auch Kerne bevorzugt benutzt werden können sollten diese etwas besser sein.
Die Kerne die der Ryzen Master mit goldenen und silbernen Sternen markiert werden aktuell unter Linux nämlich noch in einen Topf mit den "normalos" geworfen.
Hilft GPUs jetzt weniger, aber da es mit den 7000er CPUs jetzt auch GPUs auf dem CPU DIE gibt...
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
"We intend for licenses to work in the same way with Steel Nomad across Windows, macOS and Linux. As mentioned in the announcement, 3DMark for macOS and Linux will arrive later in the year, though."
Lese ich das richtig, wird Linux also nicht anders lizensiert werden als Windows, allerdings zum Launch noch nicht zur Verfügung stehen.
Hat hier schon jemand Erfahrung mit dem offiziellen Treiber von AMD gemacht? Hat der auch eine GUI so wie unter Windows? Und falls ja, hat der die gleichen Funktionen?
Ich frage deshalb, weil es ja Fluid Motion Frames ab Ende des Monats wieder im Treiber geben wird. Wäre auch für Linux interessant.
Wenn es um Hardwareunterstützung inkl. Soundkarte, AMD 7900XT, Gaming & Steam geht, ist meine Rundum-Errfahrung mit Garuda Dragonized Gaming Edition bislang am besten. Mint hat mich nicht überzeugt. Archlinux ist halt einfach aktueller. Die Grafik-Performance ist dort m.E. auf dem Niveauvon unter Windows 11. Das einziger, was mich nicht überzeugt hat, war der Raumklang, das hat aber mehr mit den fehlenden offiziellen Treiben für meine Soundblaster-Karte zu tun. Dafür funktionierte der Sound out-of-the box, was bei Mint nicht der Fall war.
@L_uk_e "damals" als ich Ende 2020 meine 6900XT ins Kubuntu System steckte brauchte man ein paar Klimmzüge und den offiziellen Treiber, damit alles läuft.
Dieser hatte damals keine GUI.
Aktuell soll er auch keine haben.
Irgendwann mit Kubuntu 12 habe ich das letzte Mal eine AMD GUI unter Linux gesehen.
Es tauchen dazu vereinzelt Rückfragen im AMD Reddit und Forum auf, aber es gab nie eine offizielle Antwort ob mit einer neuen GUI zu rechnen sei.
Ich denke im Mesa mit einigermaßen aktueller Version wird es dann funktionieren indem man wieder im System die passende Config anpasst.
Ich schließe mich mal @ApolloX an und frage was ist der offizielle Radeon Trieber für Linux? Soweit ich weiß ist alles schon im Kernel vorhanden. Es gibt nur Zusatzsoftware für die Radeon Pro, die man nach installieren kann.
Ich selbst bin mit Nobara 39, LDME 6 und Windows 10 unterwegs. Unter Win hat man zwar eine GUI, braucht man diese? Ich persönlich nicht.
Kurz zusammengefasst: Der Typ hat nen Hackintosh mit ner Radeon. Der nutzt das MPT um sich Profile zu erstellen, generiert die und nimmt die als Hex um sie irgendwie in MacOS anzuwenden. Irgendwas triezt ihn da bei den Lüftern. Wurst. Aber könnte das ein Weg sein, das MPT indirekt auch in Linux zu verwenden, denn in CortCTRL hab ich bisher nicht gesehen, dass ich beim Powerlimit deutlich über 300W komme. Also entweder müsste ich in CoreCTRL das ändern, oder schaun, ob man den Ansatz vom MacOS auch auf nem Linux anwenden kann. Aber dazu fehlen mir die Skills, um das technisch anzugehen.
Alternativ müsste man mal die Entwickler vom CoreCTRL anschreiben und fragen, woher das Powerlimit kommt. Ob das vom GPU Bios kommt, oder sie einfach gesetzt haben und auch mal ändern können.
Wenn man die Register schreiben kann und diese dann übernommen werden, sehe ich das Problem nicht.
In meinem Einzelfall kann ich teilweise die Register schreiben, aber ich interpretiere es so, es wird nicht übernommen. Der einfachste Test ist ja die Lüfterkurve zu verstellen.
Ich bezweifle AMD hat irgendetwas von den Internas von Grafikkarten öffentlich verfügbar dokumentiert.
Was da mit Reverse Enginnering, Dissassembler usw. möglich ist mag ich nicht beurteilen.
Die Kernel Config ist bis auf eine neue Option für einen CPU Scheduler (das musste ich beantworten beim aktualisieren - ist eine neue Funktion) und ein paar mehr Module für I2C usw. Sensoren zum Auslesen im Grunde immer noch gleich.
Bitteschön, frisch vom R&D-Department auf Elmors Discord-Server in persona des Users whiteshark. Nun muss nur noch 3DMarks Steel Nomad für Linux erscheinen, dann heißt es "Feuer frei!" für Bencher.
Ich hab per MPT eine *.reg Datei erstellt und ich befinde mich im Mint hier: /sys/class/drm/card0/device
In dem Folder befindet sich jetzt eine pp_table Datei im Binär Format. Was bedeutet dein hochladen/dumpen?
Ich hab per MPT eine *.reg Datei erstellt und ich befinde mich im Mint hier: /sys/class/drm/card0/device
In dem Folder befindet sich jetzt eine pp_table Datei im Binär Format. Was bedeutet dein hochladen/dumpen?
Sysfs (/sys) ist – wie du vielleicht weißt – vereinfacht gesagt ein virtuelles Dateisystem, das Schnittstellen zum Kernel / Treibern als Verzeichnisse und Dateien abbildet. Wenn du den Inhalt der Dateien in /sys/class/drm/card0/device liest / überschreibst kommunizierst du also direkt mit dem Grafiktreiber. I.d.R läuft das Textbasierend ab (z.B. pp_dpm_mclk), manchmal, speziell wenn es um Firmware-Blobs geht, aber auch als Binärdatei.
Was heißt das jetzt konkret? /sys/class/drm/card0/device/pp_table ist die aktuell vom Treiber verwendete Soft PowerPlay Table. Um die zu speichern kannst du sie einfach kopieren (z.B. mit cp oder deinem Dateimanager). Um eine modifizierte Tabelle zu verwenden übeschreibst du einfach diese Datei. Siehe auch TFM.
Das Format ist das gleiche¹ wie im VBIOS, MPTs .mpt Format (abzüglich einem Header) und dem PP_PhmSoftPowerPlayTable Registry Wert, den MPT unter Windows setzt (direkt per „Write SPPT“ oder über die .reg Datei).
Du müsstest also den hexadezimalen Wert von PP_PhmSoftPowerPlayTable in deiner .reg Datei in eine Binardatei umwandeln und diese nach pp_table kopieren oder verschieben.
Am einfachsten geht das vermutlich mit UPP, das wohl vor 4 Tagen erstmals seit 2022 wieder ein Update erhalten hat und jetzt neben Import aus der Windows Registry (also direkt %SystemRoot%\System32\config\SYSTEM einer Dualboot Windows Installation, ohne das vorher als .reg extrahieren zu müssen) auch .mpt Dateien unterstützt.
Ansosten kannst du natürlich auch deine .reg Datei umwandeln, siehe unten
[1] Mal zur Veranschaulichung:
Navi 21.rom: unter Windows mit GPU-Z gesichertes VBIOS
Navi 21.reg: Navi 21.rom in MPT geöffnet („Load“) und ohne Bearbeiten als .reg gespeichert („Save“)
Navi 21.mpt: Navi 21.rom in MPT geöffnet („Load“) und ohne Bearbeiten als .mpt gespeichert („Save“)
Code:
$ iconv -f utf-16 "Navi 21.reg" | tail -c +177 | xxd -r -p | cmp /sys/class/drm/card1/device/pp_table
# Keine Ausgabe - Navi 21.reg ist nach extrahieren der Hex-Werte und umwandeln zu binär mit pp_table identisch
$ cmp "Navi 21.mpt" /sys/class/drm/card1/device/pp_table 0x100
# Keine Ausgabe - Navi 21.mpt ist abzüglich 256 Bytes Header mit pp_table identisch
$ tail -c +7017 "Navi 21.rom" | cmp /sys/class/drm/card1/device/pp_table
cmp: Dateiende in /sys/class/drm/card1/device/pp_table nach Byte 2470, Zeile 14
# pp_table ist vollständig in Navi 21.rom enthalten
Danke dir! Auf UPP bin ich auch gekommen und saß heute vor den Installationsdateien ne Stunde und hab icht verstanden, wie ich UPP installiere oder starte. Ich hab python3, aber ich bekomm damit nichts im Terminal gestartet.
Ichhab das auch bereits bei den Anfängerfragen gespostet, aber bisher noch keine Hinweise bekommen.
@Zyxx
Mit der intensiven Hilfe von YCbCr hab ich jetzt UPP installiert. Jetzt hänge ich, da, dass ichs verwenden könnte, aber die Meldungen nicht interpretieren kann. Auch hab ich das Gefühl, weil ich Dateisystem und Ordnerstruktur von Linux nicht verstehe, dass ich garnicht in der Lage bin, das UPP einzusetzen.
Die PPT im Terminal anzuzeigen hab ich gestern mal geschafft und deren Inhalt mal kurz überflogen. Da stehen schon noch ein paar mehr Variable drin, also und @hellm bisher gerzeigt hat, aber ich vermute, dass da viele States ungenutzt sind, die also irrelevant sind.
Ich bin jetzt soweit, dass ich das hier aufgeben will. Ich verstehe von Linix nichts, man muss mir bei jeder Sache weiterhelfen, welche nicht 100% dokumentiert ist und auch exakt so funktioniert. Es ist maximal frustrierend, wenn du um einen Schritt weiterzukommen, auf fremde Hilfe angewiesen bist - bei Sachen, welche sin in den Dokus als nachvollziehbar zeigen.
Ich musste im Grundstudium mit C mal mit Pointern und Arrays programmieren und hab danach entscheiden, das wars und für den Rest des Lebens werd ich immer Leute finden, welche das Coding für mich machen. Auf dem Bereich bin ich einfach nicht talentiert, völlig ineffizient und es bleibt für mich verschwendete Zeit.
Es wäre extrem viel für das Projekt hier gewonnen, wenn sich jemand, der sich mit Linux gut helfen kann, man ins Lead ginge und einfach mal soweit vorarbeitet und hier dokumentiert, wie wir uns ohne flashen die PPTs ins Linux laden können, diese im Klartext manipulieren und dann wieder in den PPT zurückschreiben können.
Ich hab gelesen, dass CoreCTRL teilweise diese PPT Einträge sofort wieder überschreibt. Vielleicht müsste CoreCTRL dann auch weg.
Wenn man Lese-, Edit- und Schreibmöglichkeit auf die PPT hat, dann wären wir bereits ohne GUI, wo das MPT samt GUI steht.
Nicht aufgeben, lass es mal so wie es ist und warte etwas.
Ich beschränke mich bei Linuxbasteleien aktuell auch nur auf Sachen die innerhalb einer Flasche Bier lösbar sind.
Die mangelnde Doku oder das "das muss man einfach wissen" brachen mir anfangs auch oft das Genick unter Linux.
Aber wenn ich ehrlich bin, das war unter Windows damals genauso.
Mit der Zeit kommt es dann
Danke dir jedenfalls, habe das hier in die Favoriten gepackt.
Wenn ich daran basteln sollte kann ich gern ergänzen!
Es wäre extrem viel für das Projekt hier gewonnen, wenn sich jemand, der sich mit Linux gut helfen kann, man ins Lead ginge und einfach mal soweit vorarbeitet und hier dokumentiert, wie wir uns ohne flashen die PPTs ins Linux laden können, diese im Klartext manipulieren und dann wieder in den PPT zurückschreiben können.
[…]
Wenn man Lese-, Edit- und Schreibmöglichkeit auf die PPT hat, dann wären wir bereits ohne GUI, wo das MPT samt GUI steht.
Ich denke, hier müssten sich zuerst die jeweiligen „Versteher“ und Anfänger aus den Linux und MPT / Radeon OC Bereichen mal zusammen setzen, um die jeweiligen Anforderungen der anderen verstehen zu lernen.
Für mich z.B. klingt dieses Beispiel aus der UPP README nach einer nahezu exakten¹ und recht verständlichen Schritt-für-Schritt Anleitung für das, was du hier angefragt hast. Ohne anhand von konkreten Fragen nachvollziehen zu können, was daran unklar ist, könnte ich wohl auch keinen besseren Guide schreiben.
Andererseits ist es natürlich völlig nachvollziehbar, dass das für einen kompletten Anfänger nur böhmische Dörfer sind. Schließlich ist alles einfach sobald man es kann und nachvollziehbar sobald man es verstanden hat – aber eben erst dann.
Ich dagegen verstehe recht wenig bis gar nichts von GPU OC, UV, etc. In sofern ist für mich nicht unbedingt sofort ersichtlich was z.B. die relevanten Kernaspekte beim modifizieren von PPTs sind – und damit hier von besonderem Interesse.
[1] Im ersten Schritt wird zusätzlich noch die PPT aus einer VBIOS ROM extrahiert und am Ende hat man eine Datei, die man noch ins sysfs kopieren müsste. Aber in den jeweiligen Schritten einfach direkt den sysfs Pfad für --pp-file anzugeben, um sich diese extra Schritte zu sparen, erscheint mir eben als relativ triviale Transferleistung.
Danke @YCbCr
Ich kann dir mal in wenigen Stickpunkten zusammenschreiben, worum es "uns" OClern geht, das Tutorial in meiner Signatur wäre die monströse Langform.
Wir wollen unsere RDNA2 Karten (fast) beliebig tunen
In Richtung OC brauchen wir ein höheres, selbst festgelegtes Powerlimit sowie Spannungen auf Kern, SOC und VRAM
In Richtung UV fast dasslebe, nur in die andere Richtung
Das windows MPT ist ein GUI, welches die Power Play Tables ausliest, anzeigt, Werte ändern lässt und zurück in die Power Play Table schreibt - niemals das Bios schreibt/flasht. Somit kann man so gut wie nichts kaputtmachen.
Interessant wird das alles, weil Linux generell immer besser zum Spielen geeignet wird - und womöglich als schlankeres System auch in den wenigen Benchmarks die hier laufen, auch vorne mit dabei sein könnte, wenn man die PPTs selbst beschreiben kann.
So wie ich gestern mal auf angezeigte PPT gelesen hab, ist da alles drin, wo "wir" wissen, was geändert werden muss. Aber das Ändern selber, da bin ich gestern mal wieder sauber gescheitert. Im Zweifelsfall legen wir uns die MPT Screenshots neben diese Auflistung, dann kommts in etwa schon rüber, welche Variable wir da vor uns haben. Und wenn man dann mit wenigen beginnt, hangelt man sich schon durch. Faktisch sinds vermutlich wenigewr als 10 Werte, die man bis hin zum Time Spy Weltrekord ändern müsstre.
Testen kann ich immer schnell, ich hab ja den Supo (Superposition Benchmark), der ist schnell gestatrtet, zeigt mir die FPS und ich sehe bereits in den ersten drei Sekunden, opb PPT Änderungen vom System angenommen wurden.
Vor dem von dir verlinkten Beispiel saß ich gestern gut 30 min und hab versucht, das nachzustellen. Mir hauts da immer ca. 20 unlesbare Zeilen im Terminal entgehen und dann kommt ne Fehlermeldung - und in Supo ändert sich nichts. Das funktioniert bei mir also bisher so nicht.
Hauptsächlich ist mir nicht klar, wenn ich per UPP die PPT anzeige und ändere, wo befindet diese sich da gerade? Greift UPP direkt auf die unter /.../GPU0/ zu oder macht die nen Zwischenspeicherschritt - da ich eben nicht kapiere, wie/wo die Linux Befehle im Terminal zugreifen - ob das irgendwo im RAM passiert oder auf existierenden Files.
Die PPT im Terminal anzuzeigen hab ich gestern mal geschafft und deren Inhalt mal kurz überflogen. Da stehen schon noch ein paar mehr Variable drin, also und @hellm bisher gerzeigt hat, aber ich vermute, dass da viele States ungenutzt sind, die also irrelevant sind.
UPP extrahiert die Datenstrukturen für die PPTs direkt aus dem Quellcode des Kerneltreibers. In sofern handelt es sich hier quasi um eine vollständige und „offizielle“ Abbildung der PPT. Allerdings findet eben auch keinerlei Interpretation statt – UPP hat keine Ahnung, wofür die einzelnen Einträge stehen und was für Werte Sinn machen – das bleibt komplett dem User überlassen. Inklusive Möglichkeit sich massiv in den Fuß zu schießen.
CoreCtrl fasst die PPT selbst prinzipiell nicht an (soweit ich anhand des Quellcodes sagen kann). Allerdings kann es natürlich in der PPT definierte Defaults für die Dinge mit denen es arbeitet überschreiben.
@YCbCr
Das ist es, wie oben beschrieben: Ich start das Auslesen von der Karte, dann kommen Zeilen die ich nicht verstehe und unten lese ich was von nem Fehler.
andreas@andreas-Mint2:~$ upp --pp-file=vbios.pp_table extract -r vbios.rom
Extracting PP table from 'vbios.rom' ROM image...
Traceback (most recent call last):
File "/home/andreas/.local/bin/upp", line 8, in <module>
sys.exit(main())
File "/home/andreas/.local/pipx/venvs/upp/lib/python3.10/site-packages/upp/upp.py", line 469, in main
cli(obj={})()
File "/home/andreas/.local/pipx/venvs/upp/lib/python3.10/site-packages/click/core.py", line 1157, in __call__
return self.main(*args, **kwargs)
File "/home/andreas/.local/pipx/venvs/upp/lib/python3.10/site-packages/click/core.py", line 1078, in main
rv = self.invoke(ctx)
File "/home/andreas/.local/pipx/venvs/upp/lib/python3.10/site-packages/click/core.py", line 1688, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "/home/andreas/.local/pipx/venvs/upp/lib/python3.10/site-packages/click/core.py", line 1434, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "/home/andreas/.local/pipx/venvs/upp/lib/python3.10/site-packages/click/core.py", line 783, in invoke
return __callback(*args, **kwargs)
File "/home/andreas/.local/pipx/venvs/upp/lib/python3.10/site-packages/click/decorators.py", line 33, in new_func
return f(get_current_context(), *args, **kwargs)
File "/home/andreas/.local/pipx/venvs/upp/lib/python3.10/site-packages/upp/upp.py", line 317, in extract
if decode.extract_rom(video_rom, pp_file):
File "/home/andreas/.local/pipx/venvs/upp/lib/python3.10/site-packages/upp/decode.py", line 213, in extract_rom
pp_tbl_offset, pp_tbl_len = _rom_info(vrom_file)
File "/home/andreas/.local/pipx/venvs/upp/lib/python3.10/site-packages/upp/decode.py", line 93, in _rom_info
rom_bytes = _read_binary_file(vrom_file)
File "/home/andreas/.local/pipx/venvs/upp/lib/python3.10/site-packages/upp/decode.py", line 46, in _read_binary_file
f = open(filename, 'rb')
FileNotFoundError: [Errno 2] No such file or directory: 'vbios.rom'
Aber in den jeweiligen Schritten einfach direkt den sysfs Pfad für --pp-file anzugeben, um sich diese extra Schritte zu sparen, erscheint mir eben als relativ triviale Transferleistung.
Vor dem von dir verlinkten Beispiel saß ich gestern gut 30 min und hab versucht, das nachzustellen. Mir hauts da immer ca. 20 unlesbare Zeilen im Terminal entgehen und dann kommt ne Fehlermeldung - und in Supo ändert sich nichts. Das funktioniert bei mir also bisher so nicht.
Ja, das ist in der Tat ein recht nerviges Problem mit UPP: Es gibt so gut wie kein ordentliches Error-Handling und wenn man irgendwas falsch angibt haut einem das Teil einfach nen Stacktrace um die Ohren, der einem ohne in den Quellcode zu schauen oft nicht viel sagt.
Hauptsächlich ist mir nicht klar, wenn ich per UPP die PPT anzeige und ändere, wo befindet diese sich da gerade? Greift UPP direkt auf die unter /.../GPU0/ zu oder macht die nen Zwischenspeicherschritt - da ich eben nicht kapiere, wie/wo die Linux Befehle im Terminal zugreifen - ob das irgendwo im RAM passiert oder auf existierenden Files.
Grundsätzlich arbeitet UPP mit der PPT, die man mit -p bzw. --pp-file= angibt. Wenn man man nichts angibt wird als Standard /sys/class/drm/card0/device/pp_table verwendet, also (zumindest in bestimmten Distributionen) tatsächlich die „heiße“ PPT im RAM, die der Treiber gerade benutzt!
Das ist aber auch so ein Punkt mit Linux (und anderen Unix-artigen „alles ist eine Datei“ OS): Aus Sicht einer Anwendung ist eine Datei quasi nur ein abstraktes Ding, aus dem man lesen bzw. in das man reinschreiben kann. Ob die Bytes am Ende auf einer Festplatte, bei einem Treiber oder im Netzwerk landen ist ein Implementierungsdetail, um das sich der Kernel kümmert. UPP ist es egal, ob die PPT, die es gerade liest / überschreibt „live“ oder nur eine Kopie auf deiner Platte ist.
Ich kann mal versuchen, den Vorgang anhand eines konkreten Beispiels durchzugehen:
Eine kontrovers Diskutierte Änderung in Linux 6.7 war ja, dass amdgpu sich jetzt an das in der PPT vorgegebene minmale Powerlimit hält (das wurde davor einfach ignoriert / auf 0 gesetzt).
Bei meiner Referenz RX 6900 XT sind das -10 % von 255 W, gerundet auf 229000000 µW:
Code:
$ cd /sys/class/drm/card1/device/hwmon/hwmon1/
$ cat power1_cap_min
229000000
$ echo 210000000 | sudo tee power1_cap
210000000
tee: power1_cap: Das Argument ist ungültig
$ cat power1_cap
255000000
Hier sieht man auch schon den ersten Fallstrick: Auf meinem Arch Linux System die einzige GPU card1, nicht card0!
Ein einfaches upp dump fliegt mir also schon mal mit einem FileNotFoundError: [Errno 2] No such file or directory: '/sys/class/drm/card0/device/pp_table' um die Ohren…
Das bringt mich auch direkt zum ersten Schritt, dem dumpen der PPT in lesbarer Textform: upp -p /sys/class/drm/card1/device/pp_table dump > default.txt
Ich hätte mir auch vorher eine Kopie der PPT machen können cp /sys/class/drm/card1/device/pp_table default.pp_table
und diese dumpen upp -p default.pp_table dump > default.txt
Oder eine vorhandene .mpt Datei aus MPT anzeigen upp -m preexisting.mpt dump
und die dabei erzeugte preexisting.mpt.pp_table dann dumpen upp -p preexisting.mpt.pp_table dump > preexisting.txt
(hätte man auch beim ersten mal in die Datei umleiten können, dann darf man aber nicht veressen , die „Saving MPT PP table data to preexisting.mpt.pp_table“ Zeile am Anfang zu löschen …)
Die so entstandene default.txt kann ich dann in einem Texteditor meiner Wahl berbeiten, und dabei so tun, als wüsste ich, was ich tue.
In meinem Fall habe ich durch vorheriges herumspielen mit MPT herausgefunden, dass „Power Limit Minimum (%)“ im „Overdrive Limits“ Tab den Wert unter overdrive_table → min → min 8 ändert.
Diesen Wert habe ich also im Texteditor von 10 auf 20 geändert und die Datei dann als modified.txt abgespeichert.
Diese Änderung kann ich dann mit upp in eine PPT „undumpen“: cp default.pp_table modified.pp_table upp -p modified.pp_table undump -d modified.txt -w
Dank dem -d bin ich jetzt recht gut im Bilde, was alles nicht geändert wurde , aber eben auch: Changing overdrive_table.min.8 from 10 to 20 at 0x202
Die Ziel-PPT muss vorher existieren, auch wenn sie komplett überschrieben wird, daher die Kopie der default.pp_table.
Ich hätte auch direkt /sys/class/drm/card1/device/pp_table angeben können, aber dann hätte ich sudo / root bemühen müssen, da ich die PPT logischerweise als normaler User nicht einfach überschreiben darf.
So habe ich noch einen abschließenden Kopiervorgang vor mir: sudo cp modified.pp_table /sys/class/drm/card1/device/pp_table
Und siehe da:
Code:
$ cd /sys/class/drm/card1/device/hwmon/hwmon1/
$ cat power1_cap_min
204000000
$ echo 210000000 | sudo tee power1_cap
210000000
$ cat power1_cap
210000000
Das ist es, wie oben beschrieben: Ich start das Auslesen von der Karte, dann kommen Zeilen die ich nicht verstehe und unten lese ich was von nem Fehler.
[…]
FileNotFoundError: [Errno 2] No such file or directory: 'vbios.rom'
Die Fehlermeldung ist ja eigentlich recht eindeutig: Das Beispiel geht davon aus, dass man mit einem VBIOS ROM , der als vbios.rom im aktuellen Arbeitverzeichnis liegt, anfängt. In deinem Fall scheint keine Datei mit diesem Namen vorhanden zu sein.
VBIOS dumpen man übrigens folgendermaßen:
1 nach romschreiben (warum auch immer das nötig ist?)
echo 1 | sudo tee /sys/class/drm/card1/device/rom
Die Datei kopieren
sudo cp /sys/class/drm/card1/device/rom vbios.rom
Den Besitzer der Datei ändern (wenn man mit sudo kopiert gehört sie erst mal root)
sudo chown andreas:andreas vbios.rom
Im gegensatz zu Dumps, die mit GPU-Z erstellt wurden gibt es hier am Ende kein Padding – k.A. ob das relevant wäre, wenn man das Ding mal flashen wollte.
Wenn du sowas machst und selber schaun willst, ob das auch ausgeführt wird: setz die 28X Watt deiner Karte infach auf 150W und lass irgendwo laufen, wo du die FPS der Karte bei vollem Powertarget kennst. Das ist mein Standardtest. Da muss man sonst garnichts an der Karte ändern und sie muss merklich weniger FPS liefern - den Rest macht sich die Karte selber.
Ich hab gestern nur in der Powertable gesehen, dass das Limit zweimal drinsteht, mit AC und DC irgendwo dabei, was mich zwar wundert, aber wenn, dann würd ich aktuell einfach mal beide Zahlen auf diese 150W reduzieren.
Schau ich mir weiter Abends oder morgen an, jetzt muss ich mal bissl was statistisches arbeiten.
Für alle, die lieber per GUI mit der PPT herumspielen wollen:
Ich hab heute Vormittag mal angefangen, eine Okteta Strukturdefinition für die Navi 21 PPT zu erstellen.
Das Ganze ist noch ziemlich ausbaufähig (speziell Datentypen und Bezeichner) und sollte auch wirklich nur mit Navi 21 (und möglicherweise 22?) verwendet werden. Navi 23 hat wohl die gleiche SMU Version, aber eine separate PPTable_beige_goby_t Struktur, die ich nicht „übersetzt“ habe.
Allerdings hat mich fürs erste die Lust verlassen und bevors hier nur ungenutzt auf der Platte rumliegt:
@YCbCr
Deinen GUI Ansatz hab ich mir jetzt noch nicht angesehen, aber mal den Beitrag vorher mit Code nachgebaut (nicht nachvollzogen). Ich fasse mal zusammen:
Code:
upp -p /home/andreas/MPT/150W.mpt.pp_table dump > 150W.txt
cp /home/andreas/MPT/default.pp_table /home/andreas/MPT/150W.pp_table
upp -p /home/andreas/MPT/150W.pp_table undump -d /home/andreas/MPT/150W.txt -w
sudo cp /home/andreas/MPT/150W.pp_table /sys/class/drm/card0/device/pp_table
Ich hab mir also eine bestehende MPT Datei mit 150W Powerlimit genommen und über diese Schritte in die Live-Powertable geschrieben.
Und mit
Code:
upp -p /sys/class/drm/card0/device/pp_table dump > aktuellePPT1.txt
lasse ich mir vorher und nachher in ne Textdatei schreiben, was da grad drin steht.
Soweit so schlecht, denn 1) ändert sich dadurch die Power wohl nicht im laufen System und 2) nach einem Neustart steht die Power wieder bei den 285W.
Ich prüfe das immer vorher wie nachher auch mit nem kurzen Start in SuPo. Wenn ich da dieselben Start-FPS sehe, weiß ich bereits, dass all das getippe gerade garnichts gebracht hat.
YCbCr, Frage an dich: der Code oben, ist der von dir richtig adaptiert und nichts übersehen?
Frage an alle: ja, was tun? Das hilft ja alles nichts, wenn das neue Powerlimit nicht angewandt wird und nach einem Neustart das GPU Bios wieder einkal in die Powertable geschrieben wird.
CoreCTRL, LACT und nen Lüftersteuerer hab ich deinstalliert, weil ich irgendwo gelesen hab, dass CoreCTRL bei jedem Start die Powertable wieder neu überschreibt.
Bei mir musst du echt 0 Wissen und Verständnis annehmen.
, aber eben auch:
