Grundlagenartikel AMD-Grafikkarten unter Linux übertakten oder modifizieren? Geht auch!

Igor Wallossek

Format©
Mitarbeiter
Mitglied seit
Jun 1, 2018
Beiträge
10.107
Bewertungspunkte
18.598
Punkte
114
Alter
59
Standort
Labor
Coole Sache! Da wäre es ja mal eine Überlegung wert, endlich mal wieder eine aktuelle Linux Distribution zu testen...

Grüße!
 
Hi Igor,

da muss ich mich mal als Linux Radeon User zu Wort melden.
Rein technisch ist so ein Tool überhaupt nicht notwendig! Man benötigt nur root Rechte, einen Texteditor (VIM oder gEdit tuts) und eine Terminal um eine Radeon RX 480 bis Vega 56/64 zu tweaken unter Linux. Neuere Radeons habe ich leider noch nicht ausprobieren können aus Mangel an Vorhandensein ;-)
Das ganze funktioniert über das SysFs Pseudo-Filesystem von Linux. Die Kernel Entwickler von AMD haben dankenswerterweise dort genügend Schnittstellen eingebaut, dass man praktisch alle Wattman Funktionen auch unter Linux hat. Einzig die Lüftersteuerung war noch etwas ... "einfacher". Die aktuelle Doku gibts hier: https://dri.freedesktop.org/docs/drm/gpu/amdgpu.html
Man muss eigentlich nur die richtigen Texte in die richtigen SysFs Dateien schreiben und BOOOM hängt entweder der ganze Rechner, wenn man es falsch macht oder der VRAM läuft mit 940 MHz statt lahmen 800 MHz bei einer Vega 56 ;-)
Leider kann man aktuell noch nicht so viele Parameter mit dem AMDGPU Kernelmodul auslesen und überwachen wie es z.B. unter Windows mit HWInfo möglich ist, aber das wird noch...

Bei Interesse kann ich mal die ganzen Online Ressourcen in einem Guide Bündeln und auch meine Undervolting Profile für meine Vega "offen legen", das wird dann aber ein klize klein wenig Techi auf Console ;-)

Das AMDGPU Kernel-Modul zeigt eigentlich welch ein tolles System Linux ist.
 
Ich wusste schon, dass man einiges über das SysFs tweaken kann, habe mich aber noch nie so genau damit beschäftigt.
Da muss ich wohl doch mal schauen, was ich aus meiner Fury Nano noch rausholen kann. Einen Guide dazu würde ich natürlich auch gerne lesen, die Konsole würde mich dabei absolut nicht abschrecken. Wie bekommst du deine Änderungen permanent? Schreibt Systemd die Werte beim Systemstart in die entsprechenden Dateien, oder hast du das anderst gelöst?
Ich bin eigentlich bis auf wenige Ausnahmen nur noch auf Linux unterwegs. Inzwischen läuft das schon ziemlich gut mit Proton. Und normales arbeiten sowieso.
 
Einzig die Lüftersteuerung war noch etwas ... "einfacher".
Genau die Lüftersteuerung würde ich unter Linux gern in den Griff bekommen.
Meine Sapphire RadeonVII hat ein grauenhaftes Lüfterprofil.
Es gibt wilde Sprünge zwischen 800 und 3000 U/Min, aber nicht schnell genug, um die Temperatur dauerhaft unter 100°C zu halten.
Das bisher von mir genutzte amdgpu-utils kann die Drehzahl nur fest einstellen. 2000U/min sorgen dann so um die 70-80°C bei einem noch erträglichen Säuseln. Je nach Anwendungsfall geht die Last aber doch mal so hoch, dass es wieder straff in Richtung 100°C geht und im Leerlauf sind 2000U/Min völlig übertrieben. Und da wünschte ich mir schon, dass die Regelung wieder arbeiten würde.
Was ich bräuchte, wäre also eine anständige Hysterese, damit der Lüfter erst dann wieder weit runter geht, wenn es länger kalt genug ist.
 
Ich wusste schon, dass man einiges über das SysFs tweaken kann, habe mich aber noch nie so genau damit beschäftigt.
Da muss ich wohl doch mal schauen, was ich aus meiner Fury Nano noch rausholen kann. Einen Guide dazu würde ich natürlich auch gerne lesen, die Konsole würde mich dabei absolut nicht abschrecken. Wie bekommst du deine Änderungen permanent? Schreibt Systemd die Werte beim Systemstart in die entsprechenden Dateien, oder hast du das anderst gelöst?
Ich bin eigentlich bis auf wenige Ausnahmen nur noch auf Linux unterwegs. Inzwischen läuft das schon ziemlich gut mit Proton. Und normales arbeiten sowieso.
Hallo Vorgartenzwerg, bei mir läuft nur sehr wenig über Proton, weshalb ich die meiste Zeit auch unter Windoof wieder unterwegs bin, allenvoran mein Fusion360 was ich für meine CAD/3D Modelle benötige um meinen 3D Drucker zu bespaßen läuft leider garnicht auf Linux.
Leidern finde ich die OpenGL Performance von meiner Vega recht ernüchternt und unter DirectX bekomme ich halt immer noch das meiste aus meiner Radeon - leider. Bei Vulkan sieht das schon anders aus. Aber es gibt nicht so viele Vulkan spiele aktuell und auch die die es gibt hackt es mit Proton immer noch gewaltig:
* Strange Brigade hat massig Micro Studders, es wird kein Launcher gezeichnet,
* Ashes of the Singularity genau das gleich
* Die Resident Evil Remakes hab ich erstgarnicht versucht zu laufen zu bekommen.
Und Irgendwie bin ich es auch Leid via PCIe Passthrough bzw. VFIO eine zweite Grafikkarte in eine Windows VM zu schleifen um "unter Linux" ein Windows Spiel zu Spielen ;-)

Zu Deiner Frage: ich persistiere da garnichts! Ich finde das ja sogar recht reizvoll das es gerade nicht permanent ist. Da man sehr dicht am Kernel ist hat ein falscher Overclock sehr fatale Folgen! Man bekommt in 1-2 Sekunden seine komplettes OS zerschossen, sodass man rebooten muss, da es kaum Sicherheitsfunktionen gibt. "Wer auf der Ebene unterwegs ist schein wohl zu wissen was er tut", denkt sich der geneigte AMD Kernel Entwickler, weshalb das schon sehr interessant ist da rum zu wildern.
Aber ja - eine SystemD Unit wäre wohl mein Mittel der Wahl um die Befehle nach dem Startup auszuführen. Man könnte auch die Gnome Tools verwenden um nach dem Anmelden ein Script auszuführen (hier müsste man aber mittels sudo wohl noch Rechte nachschießen).
 
Genau die Lüftersteuerung würde ich unter Linux gern in den Griff bekommen.
Meine Sapphire RadeonVII hat ein grauenhaftes Lüfterprofil.
Es gibt wilde Sprünge zwischen 800 und 3000 U/Min, aber nicht schnell genug, um die Temperatur dauerhaft unter 100°C zu halten.
Das bisher von mir genutzte amdgpu-utils kann die Drehzahl nur fest einstellen. 2000U/min sorgen dann so um die 70-80°C bei einem noch erträglichen Säuseln. Je nach Anwendungsfall geht die Last aber doch mal so hoch, dass es wieder straff in Richtung 100°C geht und im Leerlauf sind 2000U/Min völlig übertrieben. Und da wünschte ich mir schon, dass die Regelung wieder arbeiten würde.
Was ich bräuchte, wäre also eine anständige Hysterese, damit der Lüfter erst dann wieder weit runter geht, wenn es länger kalt genug ist.
Hi MagicEye,

Ich versteh was du meinst. Allerdings habe ich vor etwa einem Jahr auf Wasserkühlung umgestellt mit einem Bykski Wasserblock für meine Sapphire RX Vega 56 Pulse... von daher habe ich mich nicht mehr so viel mit der Lüftersteuerung beschäftigt. Laut aktueller AMDGPU Kernel Module Doku gibt es folgende Lüfterkontrollparameter in der Schnittstelle:

"hwmon interfaces for GPU fan:

  • pwm1: pulse width modulation fan level (0-255)
  • pwm1_enable: pulse width modulation fan control method (0: no fan speed control, 1: manual fan speed control using pwm interface, 2: automatic fan speed control)
  • pwm1_min: pulse width modulation fan control minimum level (0)
  • pwm1_max: pulse width modulation fan control maximum level (255)
  • fan1_min: an minimum value Unit: revolution/min (RPM)
  • fan1_max: an maxmum value Unit: revolution/max (RPM)
  • fan1_input: fan speed in RPM
  • fan[1-*]_target: Desired fan speed Unit: revolution/min (RPM)
  • fan[1-*]_enable: Enable or disable the sensors.1: Enable 0: Disable"
Das ganze läßt vermuten das es eine einfache Hysterese gibt... aber ich habe das noch nie ausprobiert. Ich habe lediglich den pwm1_enabled auf 1 gesetzt und dann einfach für pwm1 einen Wert gewählt der mir gefiel, ähnlich wie Du. Bei Gelegenheit könnte ich einmal mit den Parametern spielen und schauen wo mein PWM Signal hin schnuppst. Aber wie gesagt, ich laufe "unter Wasser" mit heißen 50 Grad oder so. Unter Linux wird meine Vega doch ab und an mal 13 Kelvin/Grad Celsius heißer als unter Windows. Das Power Management ist definitiv DEUTLICH anders.... :-/
 
Ich hatte bisher nur passiv gekühlte Karten oder solche mit einem dicken Eigenentwurf des Herstellers. Die waren alle so leise, dass mir eine evtl. Lüfterkurve nie auffiel. Aber die VII gabs ja leider nur im Referenzdesign.
Die Parameter klingen auf jeden Fall vielversprechend, das schaue ich mir bei Gelegenheit mal an, Danke!
 
Es gibt aber im Treiber Restriktionen (für Navi), die man so einfach per Script nicht aushebeln kann. Voltage und Power Limit sind nicht ganz ohne und das Handling ist sogar zwischen den Treiber-Versionen unterschiedlich. Das Tool hat den Vorteil, das man das ganze System faktisch on-the-fly modden kann, ohne Scripte und permanente Eingriffe zu bemühen. Das hat den Vorteil, dass man nach einem Crash weniger Probleme hat bzw. man sich schneller herantasten kann. Genau deshalb hat sich AMD ja auch dieses Tool selbst programmiert.

Die Fan-Parameter oben sind ja genau das, was wir auch im MPT haben, nur ist AMDs Lüftersteuerung crazy und nutzt eben keine einfache Hyterese. Vor allem das automatische Unwesen ist fürchterlich. Manuell fest einstellen geht meist, aber das will ja niemand. :D
 
@Marf ich habe auch einmal ein paar Runden strange brigade gezockt per wine/proton mit einer vega64 auf 4k soagar und ich hatte da keine andauernden ruckler, es lief absolut performant und sah auch sehr schön aus :)

hier noch zur anregung eine gui, die mir gerade eben über den weg gelaufen ist. ich werde sie dann aber erst nach der arbeit tedten können. heute nachmittag. https://www.gamingonlinux.com/2020/06/amd-wattman-like-open-source-app-corectrl-adds-navi-support

das ist auch nicht die erste gui die einem die konfiguration erleichtert.
 
CoreCtrl sieht ja mal richtig gut aus. Erinnert natürlich stark an Wattman, was ja nicht unbedingt schlecht ist.
Das werde ich auch ausprobieren.
 
...
hier noch zur anregung eine gui, die mir gerade eben über den weg gelaufen ist. ich werde sie dann aber erst nach der arbeit tedten können. heute nachmittag. https://www.gamingonlinux.com/2020/06/amd-wattman-like-open-source-app-corectrl-adds-navi-support
...

Danke für den Hinweis Alexander! Ich habe kurz in den Source Code von CoreCtrl geschaut. Dort wird auch das SysFs amdgpu Kernel Module Interface benutzt für das Monitoring und das Voltage/Clock Tweaking (man muss ja nicht nur immer Overclocken ;-)) (was ja eigentlich nicht überrascht...)
Freut mich das es nun was für den Ottonormal User gibt. Ich hatte auch schon überlegt ein solches Projekt zu starten und eine GUI für eine "Scripte" (also diese 10-Zeiler...) zu schreiben. Aber das hat sich wohl jetzt erledigt! :-D Da bin ich wohl eindeutig zu spät dran. *lach*

Mich würde mal interessieren ob die Lüftersteuerung im CoreCtrl was taugt... Im Zweifelsfall kann man ja mit Python oder der Bash ein kleines Tool schreiben was aktiv die Temperatur überwacht und laufend das Fan PWM Signal anpasst.

@Igor Wallossek

für das verwenden der SysFs amdgpu Schnittstelle muss eigentlich nicht viel gemacht werden im System. Es muss ein Kernel Module Parameter beim Boot gesetzt werden, mit einer Bitmaske welche PP_OD Features aktiviert werden (Im Zweifel einfach alle ;-) ). Aber ja... das ist ein Systemeingriff wie aber eigentlich jedes OC/UV ;-)
Die "Scripte" (wenn man das so nennen will) um das Tweaking dann wirklich vorzunehmen sind ziemlich trivial. Hier ein Beispiel:
#!/bin/bash
cd <böser_pfad>;
echo "MagieZumAktivieren" > musst_du_selbst_nachlesen &&
echo "s 1 991 900" > pp_od_clk_voltage &&
echo "s 2 1138 950" > pp_od_clk_voltage &&
echo "s 3 1269 1000" > pp_od_clk_voltage &&
echo "s 4 1312 1050" > pp_od_clk_voltage &&
echo "s 5 1455 1100" > pp_od_clk_voltage &&
echo "s 6 1520 1150" > pp_od_clk_voltage &&
echo "s 7 1590 1200" > pp_od_clk_voltage &&
echo "m 3 800 950" > pp_od_clk_voltage &&
echo "c" > pp_od_clk_voltage;
echo "165000000" > .<selbst_nachlesen_;-)>/power1_cap;
cd <anderer_böser_pfad>;
echo "1" > pwm1_enable &&

echo "95" > pwm1;

Das Beispiel setzt auf einer Vega GPU das Power State 1 bis 7, deren Takt [MHz] und Spannung [mV], sowie den letzten Memory Clock State (auch mit Takt und Spannung). Wer es nicht gemerkt hat, im Beispiel sind die Standardwerte für eine Vega 56
Dann wird noch das PowerLimit auf 165 W bzw. 165000000 Micro Watt festgelegt sowie die Lüftersteuerung auf einen konstanten Wert gesetzt 95/255 also etwas weniger als 50% Maximale Drehzahl.
Das Ganze ist eigentlich so trivial das man eigentlich gar kein weiteres Tool benötigt.

Was die Kernel Module/Treiber Beschränkungen angeht kann ich dich nun bestätigen. AMD war fleißig und hat wohl im amdgpu Module jetzt Checks eingebaut. Zumindest kann ich nicht mehr die 395 Watt Powerlimit setzen, was vor ca. 1,5 Jahren funktionierte! :-D Jetzt ist bei 249W bei meiner Sapphire Vega 56 Pulse Schluss. Das Risiko dass man sich die Karte Ausglüht ist also deutlich niedriger geworden, was mich freut.

Aber nicht das Du mich falsch verstehst: Ich finde es richtig Klasse das Du einen Artikel/ein Video zum Thema Linux Tweaking gemacht hast! Ich hoffe ja immer noch das z.B. Ubuntu irgendwann so Mainstream geworden ist wie Windows und alle Anwendungen Betriebssystem agnostisch laufen *träum*
 
@Marf ich habe auch einmal ein paar Runden strange brigade gezockt per wine/proton mit einer vega64 auf 4k soagar und ich hatte da keine andauernden ruckler, es lief absolut performant und sah auch sehr schön aus :)

hier noch zur anregung eine gui, die mir gerade eben über den weg gelaufen ist. ich werde sie dann aber erst nach der arbeit tedten können. heute nachmittag. https://www.gamingonlinux.com/2020/06/amd-wattman-like-open-source-app-corectrl-adds-navi-support

das ist auch nicht die erste gui die einem die konfiguration erleichtert.

strange brigade hat doch vulkan. das sollte eigentlich sehr gut auf linux laufen

funktioniert bei CORECTRL der CPU reiter schon?
 
@longusnickus

Direkt schlecht läuft es nicht (bei mir). Ich habe im Benchmark von Strange Brigade ~85 FPS unter Ubuntu 20.04 mit einer Untervolteten Vega 56. Mit den gleichen Radeon Settings unter Windows bekomme ich ~93 FPS. (Alles auf Hoch, AA: aus, Tesselation: aus, AsyncComupte: An, 3440 x 1440 Auflösung, Vulkan API, Sapphire RX Vega 56 Pulse, Ryzen R5 3600 Stock, Crucial Ballistix DDR4-3600 CL 16 @ 3733 MHz MCLK&FCLK)

Die Differenz ist nicht so hoch und höchstwahrscheinlich auf CPU Overhead in Proton/SteamPlay zurückzuführen. Was aber sehr offensichtlich ist bei mir, ist das die Unevenness (Igor sei dank für diesen Term! :-D) deutlich besser ist unter Windows. Bei schnellen Kamerafahrten stockt das Bild gerne mal 125 - 250ms oder so. Den FPS stört das kaum, aber ich merke halt einen Hänger. In vielen Spielen habe ich das :-( Auch in offiziell unterstützten SteamPlay Spielen. Deswegen bin ich auch zum Zocken wieder zurück auf Windows :-/ Auch wenn alles andere unter Ubuntu gefühlt doppelt so schnell ist.
Wobei ich mal schauen müsste... vlt. kann ich das eindämmen wenn ich das Spiel auf meine Samsung NVMe SSD schiebe statt meine RAID0 HDD zu benutzen... Mal testen! Kaum redet man darüber, kommt man auf Ideen wie man es lösen könnte ;-) Danke Longusnickus! :-D

Ich lass mich mal überraschen wie sehr Microsoft die DirectX Schnittstelle für Linux kaputt macht, damit alle schön auf Windows bleiben zum Daddeln :ROFLMAO: Wie war das... Embrace, Extend, Extinguish?
 
jedenfalls sobald Microsoft Skype übernommen hatte war das nicht mehr zu gebrauchen für Linux, selbs als die dann einen neuen Client gebracht haben. Aber das gute ist auch, es gibt einen weit besseren Client - Discord :D

Ich glaube da immer noch dran, dass die selbstverständlich versuchen Linux klein zu halten um mit ihrem eigenen Angebot mehr Geld verdienen zu können.
 
Für meinen Ryzen 3000er zumindest und das geht sicher bei jeder CPU kann ich in dem corectrl dann ganz einfach festlegen welcher Cpu Governor benutzt werden soll, also Ondemand, Performance oder CPU utilization. Ich denke mal Cpu utilization sollte schedutil sein.

Fürs daddeln ist ja immernoch Preformance am besten. Und da man jetzt damit einfach zum Beispiel die SpellForce.exe die mit Proton dann läuft angeben kann braucht man das nur einmal einstellen in der GUI und sobald das Spiel startet wird automatisch der Governor angepasst :)

Wenn man dann im Globalen Profil entsprechend die GPU auf powersave oder ähnlich und die CPU auf ondemand einstellt, dann wechselt das nach dem Spielen entsprechend in den stromsparenderen Modus zurück :)

Ein kleiner haken an dem Programm ist, dass man beim start einmal die sudo Abfrage bestätigen muss durch die Passwortabfrage. Gäbe es villeicht optional zumindest einen Systemdienst der die einstellungen übernimmt und die GUI "nur" die einstellungen aufnimmt und die Statistiken zeigt, dann würde man nach der ersteinrichtung sogar ohne die sudo abfrage auskommen. das wurde bei radeon-profile soweit ich weiß so gemacht.

Aber einmal beim start das Passwort einzugeben, damit kann ich auch gut leben :)

(Ich bin mir gerade nicht ganz sicher, das mit den root rechten dürfte bei Wayland umgebungen probleme bereiten, so dass die GUI nur für X11 benutzbar ist -noch nicht getestet-)
 
Ich habs gerade mal getestet → corectrl meldet unter Wayland dann einfach "Cannot start helper" (getestet mit sway)
 
Du kannst dir den Aufwand sparen. Dafür gibt es amdgpu-clocks. Das bringt auch gleich eine systemd-Unit mit. Entgegen des Readme würde ich persönlich diese aber nicht in /lib/systemd/system/ ablegen sondern in /etc/systemd/system/.

Mir sagt der Ansatz mit der Konfigurationsdatei (deklarativ) mehr zu als ein selbstgestricktes Skript (imperativ).
 
Zuletzt bearbeitet :
Klar man kann alle Einstellungen auch umständlich über das Terminal einstellen oder ein overclocking script erstellen.
Aber mittlerweile gibt es auch Programme wie Radeon Profile die einen ähnlichen Funktionsumfang wie unter Windows bieten und dabei einfach und zuverlässig zugleich sind; Inkl. Erstellung diverser Lüfterkurven, div. Übertaktungprofile, Autostart ohne sudo beim booten (Musste bei mir allerdings unter Mint 19.3, Cinnamon eine Autostartverzögerung von einigen Sekunden eingeben weil er sonst hängen blieb.
Wattman habe ich auch probiert ist allerdings noch beta und es ist noch nicht der volle Funktionsumfang zugänglich.

Hier habe ich mal einige Bilder von mir angefertigt:
4373
4374
43754377
 
Ich lass mich mal überraschen wie sehr Microsoft die DirectX Schnittstelle für Linux kaputt macht, damit alle schön auf Windows bleiben zum Daddeln :ROFLMAO: Wie war das... Embrace, Extend, Extinguish?

MS kann machen was sie wollen. Ich hoffe, dass mehr Entwickler auf Vulkan umsteigen.
Wenn man noch ein bisschen an Vulkan schraubt, dann hat DX einfach keine Vorteile mehr, sondern nur den Nachteil, dass man mit jeder Portierung auf ein anderes Gerät (linux/stadia, android, switch, ps,..) die API wechseln muss.
Würden alle Vulkan nutzen und unterstützen, dann hätten Entwickler viel weniger Arbeit
 
Oben Unten