Radeon @ Linux

Frage an dich: der Code oben, ist der von dir richtig adaptiert und nichts übersehen?
Also mal grundsätzlich scheinst du alles richtig gemacht zu haben… Aber
Ich hab mir also eine bestehende MPT Datei mit 150W Powerlimit genommen und über diese Schritte in die Live-Powertable geschrieben.
Ich nehme mal an damit ist gemeint, dass du in MPT unter „Power“ → „Power Limit (W)“ den Wert 150 eingetragen hast, nicht „OC Limits“ → „Overdrive“ → „Power Limit“ → „Min“ / „Max“?

MPT überschreibt dann die Werte smc_pptable.SocketPowerLimitAc[PPT_THROTTLER_PPT0] und smc_pptable.SocketPowerLimitDc[PPT_THROTTLER_PPT0] in der PPT mit dem eingegebenen Wert. Diese beiden Werte scheinen den Linux Treiber allerdings nicht großartig zu beeindrucken: Sowohl power1_cap_default, als auch power1_cap bleiben unverändert.

Also alles Essig? Nicht wirklich: Es gibt (imo) keinen guten Grund dafür überhaupt die PPT zu verwenden. Das Powerlimit kannst du auch jederzeit via power1_cap beliebig ändern, solange der neue Wert innerhalb von power1_cap_min bis power1_cap_max liegt.

Diese beiden Werte werden dagegen tatsächlich aus der PPT übernommen. Wenn du dein Powerlimit auf 150W senken willst müsstest du also
  1. smu_11_0_7_overdrive_table.min[SMU_11_0_7_ODSETTING_POWERPERCENTAGE] (overdrive_table.min.8in upp; „OC LImits“ → „Overdrive“ → „Power Limit“ → „Min“ in MPT) in der PPT auf einen passenden Wert setzen (Wenn deine GPU 285 W als Standard hat also mindestens 48)
    • power1_cap_min sollte dann einen Wert von 149000000 haben
    • Wenn dein Kernel älter als Linux 6.7 ist sollte da eh 0 drin stehen, dann kannst du dir den Schritt auch sparen
  2. 150000000 nach power1_capschreiben
    • Dafür kannst du auch CoreCtrl benutzen
Und ja, all diese Änderungen (an pp_table, power1_cap, etc.) überleben immer nur so lange, wie der Treiber geladen ist. Wenn du also willst, dass die nach einem Neustart noch gelten musst du dafür sorgen, dass sie nach jedem Start (nachdem amdgpu geladen wurde und die GPU initialisiert hat) neu geschrieben werden, z.B. mit einer udev-Regel.
CoreCTRL, LACT und nen Lüftersteuerer hab ich deinstalliert, weil ich irgendwo gelesen hab, dass CoreCTRL bei jedem Start die Powertable wieder neu überschreibt.
CoreCtrl kann die PPT (wie ich schon mal geschrieben habe) allein aus dem Grund schon nicht überschreiben, dass (zumindest im master Branch) kein Code existiert, um überhaupt auf die PPT zuzugreifen. Was CoreCtrl, etc. kann und tut ist Werte überschreiben, deren Default- und/oder Grenzwerte aus der PPT stammen z.B. eben power1_cap.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Genau, ich habs mit den beiden versucht:

smc_pptable:
SocketPowerLimitAc:
SocketPowerLimitAc 0: 150
SocketPowerLimitDc:
SocketPowerLimitDc 0: 150

Weil das halt aus der MPT Datei die Stelle ist, wo man das reinschreibt.

Du weißt ja, wenn du mir sowas wie "power1_cap" nemmst, musst mir sagen, wo ich das finde und wie ich das ändere. In der PP Table befindet sich das nicht, richtig?
Ich bin hier auf Kernel 6.5.0-26, bin da also von den Einschränkungen noch nicht betroffen. CoreCTRL kann mir irgendwas über 300W maximal geben, aber ich will ja wesentlich höher (600W+) und muss dazu aber auch eine ganze Litanei an weiteren Werten drehen. Hier Hilft mir CoreCTRL nicht weiter, da müsste ich ne MPT Datei aus Win nehmen und hier raufladen.

Verstehe ich richtig, dass ich das minimal untere sowie maximale obere Limit außerhalb der PP Table ändern muss und anschließend CoreCTRL innerhalb dieser gesetzten Limits arbeiten könnte?
Das würd mir bissl helfen, aber nicht alles, den ich muss auch z.B. den FCLK erhöhen, der mir in CoreCTRL nicht angezeigt wird.
 
Du weißt ja, wenn du mir sowas wie "power1_cap" nemmst, musst mir sagen, wo ich das finde und wie ich das ändere. In der PP Table befindet sich das nicht, richtig?
Entschuldige, die power1_* Dateien liegen unter /sys/class/drm/card1/device/hwmon/hwmon1/.
Bei mir findet such dort z.B.
Code:
$ ls -l power1_*
-r--r--r-- 1 root root 4,0K  7. Apr 16:43 power1_average
-rw-r--r-- 1 root root 4,0K  7. Apr 16:43 power1_cap
-r--r--r-- 1 root root 4,0K  7. Apr 16:43 power1_cap_default
-r--r--r-- 1 root root 4,0K  7. Apr 16:43 power1_cap_max
-r--r--r-- 1 root root 4,0K  7. Apr 16:43 power1_cap_min
-r--r--r-- 1 root root 4,0K  7. Apr 16:43 power1_label
hwmon ist die Standard Kernel Schnittstelle / Schema für Sensoren aller Art.

power1 ist der Sensor, die einzelnen Dateien sind bestimmte Attribute. Wenn man jetzt z.B. ein Programm schreiben wollte, dass die Leistungsaufnahme als Graph darstellt würde man _average in regelmäßige Abständen auslesen und den Wert anzeigen. _cap wäre die Obergrenze und _label der Name des Sensors.

Wie man sehen kann ist die power1_cap Datei im Gegensatz zu den anderen beschreibbar (hat ein w bei den Berechtigungen). cap_min, cap_max und cap_default sind dann hoffentlich selbsterklärend.

In dem Verzeichnis findest du auch andere Sensoren wie fan1 um die Lüfter Drehzahl auszulesen (oder zu überschreiben) temp1-3 für edge/junction/mem, etc. Diese Dateien Grafisch darzustellen ist im Prinzip alles was CoreCtrl macht.


Verstehe ich richtig, dass ich das minimal untere sowie maximale obere Limit außerhalb der PP Table ändern muss und anschließend CoreCTRL innerhalb dieser gesetzten Limits arbeiten könnte?
Nicht ganz, das maximale obere Limit müsstest du in der PPT ändern, was sich dann außerhalb (in power1_cap_max und damit auch CoreCtrl) widerspiegeln sollte. Allerdings wird es wohl für Extremwerte wie 600 W nicht reichen, nur die künstliche Begrenzung auf 300 W aufzuheben. Aber an was man dafür alles rumdrehen muss wirst du wohl am besten wissen.
Das würd mir bissl helfen, aber nicht alles, den ich muss auch z.B. den FCLK erhöhen, der mir in CoreCTRL nicht angezeigt wird.
Welche Power Level verwendet werden kannst du ja über /sys/class/drm/card1/device/pp_dpm_fclk festlegen. Wo die Frequenzen für die einzelnen Level herkommen ist mir allerdings nicht wirklich klar.
In der PPT sind zwar an zwei Stellen FCLK Frequenzen definiert, diese stimmen aber nicht mit den Werten, die der Treiber tatsächlich verwendet überein:
Bildschirmfoto vom 2024-04-07 17-26-13.pngBildschirmfoto vom 2024-04-07 17-26-33.png
Code:
$ cat pp_dpm_fclk
0: 500Mhz
1: 1176Mhz *
2: 1941Mhz
Die Werte aus der PPT werden also entweder gar nicht, oder nur als Berenchungsgrundlage verwendet.
Aber damit kannst du ja selbst noch rumspielen, bei solchen Sachen bin ich raus (fachlich, sowie bzgl. an meiner eigenen Karte ausprobieren).
 
AMDs AFMF (also Fluid Motions Frames) wird jetzt wieder in den Treiber integriert. Wird man das wohl auch irgendwie unter Linux nutzen können?
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh