Radeon @ Linux

[YCbCr]

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.

 

[ApolloX]

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.

 

[YCbCr]

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.

$ 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:

$ 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).

 

[L_uk_e]

AMDs AFMF (also Fluid Motions Frames) wird jetzt wieder in den Treiber integriert. Wird man das wohl auch irgendwie unter Linux nutzen können?

 

[Morpheus600]

Wird glaube nicht kommen. Ist halt Linux. Sieht man ja mit FSR. Gibt es ja auch keine vernüftige Lösung.

Und vielleicht sollte man das noch mit den den Startbeitrag rein nehmen. Da ja CoreCTRL mit RDNA3 nicht funktioniert habe ich etwas anderes gesucht und bin auf LACT gestoßen. Funktioniert einwandfrei. Auch beim Booten übernimmt er alle Settings.

 

[Pirate85]

Huh? Via Gamescope kannste doch FSR nutzen? oO

 

[Morpheus600]

Gamescope ist auch keine richtige Lösung finde ich. Inputlag ohne Ende damit. Zu dem gibt es einen Maus Bug das die Hardwarebeschleunigung nicht mehr funktioniert.

 

[Pirate85]

Du verwendest den normalen AMD Treiber oder? Hast du mal die mesa Treiber von Kisak probiert?

Ich hab damit absolut 0 Probleme mehr (Mint 22 Cinnamon) - mir ist allerdings auch keinerlei Bug mit der Hardwarebeschleunigung vorher aufgefallen.

 

[Morpheus600]

Ich verwende den Mesa Treiber.
Und hier nur ein Beispiel zum Maus Problem: https://github.com/ValveSoftware/gamescope/issues/1145

 

[Pirate85]

Genau eben jener Kisak hat dort gepostet dass das Problem gefixt ist.

Ich muss dazu sagen ich bin erst seit ein paar Wochen mit Mint bzw überhaupt Linux unterwegs - mir ist es nie aufgefallen. 🤷🏻 (Und das würde auffallen )

Edith: Ich hattes bspw. bei diversen Sachen - vor allem aber bei manchen Spielen - Grafikglitches und/oder Stutter, hat ne Weile gedauert bis ich drauf gekommen bin einfach mal andere mesa Treiber zu verwenden.
Allgemein da erstmal einigermaßen durchzusteigen ist nen Akt, zumindest wenn man von ner Windows-Only Perspektive da rein kommt.

 

[Morpheus600]

Mit Gamescope ist bei mir die Maus deutlich langsamer. Habe schon alles versucht. Nichts hilft.

Beitrag automatisch zusammengeführt: 03.09.2024

Aber ist egal. Gamescope schmiert sowieso Regelmäßig bei mir ab wenn ich Hunt Showdown Zocke. Daher kommt es sowieso nicht ion Frage. Und würde es auch nur wegen HDR nutzen.

 

[L_uk_e]

Hä? Sobald es FSR in spielen gibt, dann kann man das auch einstellen. Hab noch kein Spiel gehabt bei dem das nicht funktioniert hat.

 

[Pirate85]

Dito, ich versteh es auch nicht. Hat vielleicht was mit Arch oder falschen Einstellungen zu tun? Wenn FSR im Spiel selbst implementiert ist läuft es so oder so top (da wäre es auch Quatsch FSR via Gamescope zu nutzen) - und sonst bei Spielen ohne natives FSR funktioniert Gamescope ohne jegliche Probleme.

Hatte die letzten Tage alles von nativen Apps auf Flatpak umgestellt, seitdem funzt es sogar Problemlos übergreifend zwischen den Launchern (Ich nutze Lutris & Steam - beides mittlerweile Flatpak)

 

[Morpheus600]

in Spielen,ja. Das ist ja logisch. Es ging doch aber um AFMF was Treiberseitig aktiviert werden kann in Windows.
Ich und ich habe geschrieben das es wohl nie oder später kommen wird. Wie FSR was es bis heute nicht Treiberseitig gibt in Linux. Außer man nutzt Gamescope wo man FSR1 aktivieren kann wenn das Spiel selbst kein FSR kann.

 

[Pirate85]

Linux hängt immer Treiberseitig hinterher - was an sich kein Beinbruch ist.

Ich habe - nur als Beispiel - unter Windows in Warthunder mit den aktuellen AMD Treibern ab und an Grafikglitches am Boden die es unter Linux absolut nicht gibt...

Gib den Jungs bisschen Zeit.

 

[Morpheus600]

Mir ist das egal. Ich bin nur auf die Frage von L_uk_e eingegangen.

 

[L_uk_e]

und sonst bei Spielen ohne natives FSR funktioniert Gamescope ohne jegliche Probleme.

ohne jegliche Probleme funktioniert aber Gamescope selbst nicht. Bei mir ist Hunt Showdown damit auch unspielbar weil es immer abstürzt.

Es ging doch aber um AFMF was Treiberseitig aktiviert werden kann in Windows.

Und um FSR. Siehe:

Sieht man ja mit FSR. Gibt es ja auch keine vernüftige Lösung.

Wobei ich weiß was du meinst...dass man es eben einfach zentralseitig in einer quasi GUI oder so vom Treiber selbst aktivieren kann.
Es gibt ja aber auch keine GUI für den Treiber wenn ich das richtig sehe.
Ich nutze Gamescope nur in Spielen in denen ich HDR nutzen will und somit auch nur in Single Player Spielen. Und dann funktioniert das ganze auch nur in Steam und nicht z.B. in Battle.net und somit eben auch nicht in Diablo 4

Wobei es bei letzterem auch eher daran liegt, dass man den Battle.net Launcher auch nur irgendwie umständlich installieren kann.

 

[0ldn3rd]

Sorry für reinkrätschen hier, aber hab den Thread gerade erst entdeckt...

CoreCtrl unter Nobara (RX7900XTX) hab ich gefunden und komme soweit damit klar, was ich aber vermisse ist die "komfort-Lösung" eine Ziel-FPS Vorgabe zu machen. Hab ich da was übersehen, oder muss ich ein anderes Tool nehmen? Oder geht das (aktuell) nicht?

 

[Morpheus600]

Was Meinst du mit Ziel-FPS ? Die FPS Begrenzen ?

 

[0ldn3rd]

@Morpheus600 Ja, genau!

 

[Morpheus600]

Dazu nutze ich Goverlay mit Mangohud. Nobara hat aber noch eine alte Version von Goverlay. Version 1.1. Damit kann man nur feste vorgegebene FPS Einstellen. Man kann auch im Steam per Startbefehl die FPS Begrenzen.
Aber ich würde sagen installiere dir erst mal Goverlay und schaue dir das mal an.
Und siehe mein Bild. Bei der Version 1.1 fehlt das Offset. Und es ist auch ein bisschen verbugt. Ich nutze 120fps mit -3. Ist es aber einmal eingestellt dann behält er die Einstellung

 

[BuffaloPaps]

In der conf Datei von MangoHud kann mit einem Texteditor jede gewünschte FPS Grenze konfiguriert werden.

 

[Pirate85]

Ich habe - nachdem mir Windoof Linux zerschossen hatte, nun ne andere Lösung (2 SSD / 2 OS, eine immer deaktivert) und gleich bisschen was anders gemacht bei Mint... alles auf Flatpak gesetzt. Problem: Ich kriege keine "allgemeine" Config für Mangohud mehr hin, wie es vorher mit nativen Apps Problemlos möglich war.

Muss mich jetzt auch erstmal neu reinfuddeln... mit Flatpaks ist alles anders (und Teilweise komplizierter).

 

[0ldn3rd]

@Pirate85 Ja, über die Jahre ist bei mir auch die Erkenntnis gereift, dass alle Dul-Boot, usw Lösungen früher oder später irgendwas zerlegen! Ich bin da schon seit Jahren bei der getrennten Festplatten/SSD Thematik mit der Bootmenü Auswhl über BIOS/UEFI.

Die M.2 machen einem das Leben an der Stelle allerdings nicht immer angenehmer! (Mal schnell zur Sicherheit abstecken ist da ja nicht mehr)

 

[Morpheus600]

Flatpak soll wohl in gewissen Situationen besser laufen aber man ist damit auch sehr eingeschränkt.
Und ich habe Windows und Linux auch auf 2 verschiedenen Platten. Und wechsel im BIOS wenn ich Mal Windows nutzen möchte was sehr sehr sehr selten vorkommt seit ich Linux nutze.

 

[Pirate85]

Ich machs exakt wie du Morpheus - Win/Linux auf 2 verschiedenen NVMe und je nachdem welches OS ich nutze, ist die andere deaktiviert - hat mich die Tage erst nen Kumpel drauf gebracht.

Aber mit dem Flatpak Zeugs... so richtig werde ich damit jetzt noch nicht warm. Hatte auch bei der Gelegenheit mal geschaut wie weit der native MESA Treiber von AMD mittlerweile ist... hängt nach wie vor gut hinterher.

 

[Morpheus600]

Was meinst du mit hängt hinter her?

 

[Pirate85]

Versionstechnisch hängt er hinterher. Ich hab bspw in Warthunder oder Dead Island 2 mit den Standard Mesa Treibern ordentliche Probleme bei der Darstellung, mit den Kisak absolut keine.

 

[Zyxx]

Naja, Kisak ist ja im Endeffekt auch nur eine Quelle für neuere Dateien, da die Maintainer das bei ihrer Distri nicht so schnell nachziehen.
Mint ist ja auch nur ein Long Term Linux, gibt es da eventuell nen testing Zweig?

Hier mit Debian Testing fahre ich ganz gut... Sys läuft und Mesa ist recht frisch.

 

[Pirate85]

Nicht das ich wüsste, man könnte sich z.b. Ubuntu Cinnamon mal anschauen - Ubuntu selbst ist immer nen Tick fixer.
Aber nen Testing Zweig habe ich bisher noch nie ausprobiert. Muss aber auch sagen das ich nach wie vor nen gut strukturierten Desktop benötige da vieles für mich noch ungewohnt ist - Cinnamon ist z.b. für mich wesentlich eingänglicher als KDE oder Gnome - mit letzerem komme ich überhaupt nicht zurande.