AMD iGPU unter Linux: Eine Leidensgeschichte mit Happy End (für NVIDIA)

Ich habe eine AMD iGPU. Und ich sage euch, die hat mir mehr Kopfschmerzen bereitet als jede NVIDIA-GPU, die ich je unter Linux betrieben habe. Glaubt es oder nicht.

Die integrierte Grafik des Ryzen 7 7800X3D ist, gelinde gesagt, "grenzwertig benutzbar". Seit ich diesen Prozessor besitze, produziert die iGPU immer wieder sogenannte Switch Timeouts, Page Flip Timeouts und mehr, bei denen das komplette System einfach einfriert. Nichts geht mehr. Harter Reset. Danke, AMD.

A dramatic promotional-style image depicting the rivalry between AMD and NVIDIA graphics cards on Linux, with Tux the Linux penguin mascot standing in the center. The background is split into two clashing sides — a red, lightning-streaked side on the left bearing the AMD logo, and a green, lightning-streaked side on the right bearing the NVIDIA logo — visually representing the competition between the two GPU manufacturers for Linux driver support and performance.

Was sind Switch Timeouts überhaupt?

Für alle Neulinge hier kurz erklärt: Ein "GPU Switch Timeout" tritt auf, wenn die GPU nicht rechtzeitig auf einen Befehl des Treibers reagiert. Der Kernel wartet, wartet und wartet, und entscheidet dann, den Treiber zurückzusetzen und im schlimmsten Fall das System einfriert. Unter Linux äußert sich das typischerweise darin, dass der Bildschirm schwarz wird oder das System komplett aufhört zu antworten, wie in meinem Fall.

Warum ich die iGPU überhaupt brauchte

Jetzt kommt der lustige Teil. Ich wollte die iGPU eigentlich gar nicht für rechenintensive Aufgaben nutzen. Der Grund war ein ganz anderer: NVIDIA unterstützte damals noch kein "Explicit Sync" in ihrem Treiber.

Was ist Explicit Sync? Kurz gesagt: Es ist ein Mechanismus, über den Wayland und der GPU-Treiber sich absprechen, wann ein Bild fertig gerendert ist und angezeigt werden darf. Ohne Explicit Sync kann es unter Wayland dazu kommen, dass Frames in der falschen Reihenfolge angezeigt werden, sobald eine Anwendung die Bildwiederholrate des Monitors nicht einhält. Das Ergebnis: Sichtbares Tearing, Ruckler, Bilder in der falschen Reihenfolge, also alte Frames, die plötzlich zwischen neuen auftauchen. Generelles Chaos, besonders in Spielen.

Die Lösung damals war also: Die AMD iGPU übernimmt die Displayausgabe und kümmert sich um Wayland, während die NVIDIA-Karte die schweren Aufgaben wie Spiele oder GPU-Berechnungen übernimmt. Zum Glück ist das ein Setup, das seit Jahren unter Linux einwandfrei funktioniert. Ihr steckt einfach eure Monitore in die AMD GPU, installiert den NVIDIA-Treiber, und alles läuft. Manchmal muss man einer Anwendung zwar explizit sagen, dass sie auf der dedizierten, also der NVIDIA-Grafikkarte, laufen soll. Aber das ist auch schon alles.

Unter GNOME-basierten Desktops könnt ihr dazu einfach die Anwendung im Launcher rechtsklicken und die Option "Auf dedizierter Grafikkarte ausführen" wählen. Läuft eine Anwendung standardmäßig auf der dGPU, steht dort entsprechend "Anwendung mit integrierter Grafikkarte ausführen".

Unter KDE ist es nicht ganz so elegant. Dort müsst ihr den Startmenüeintrag bearbeiten und unter "Erweitert" die Option "Mit dedizierter Grafikkarte ausführen" aktivieren und speichern.

A screenshot of the KDE Menu Editor (KDE-Menü-Editor) on Linux, showing advanced launch settings for the Steam application, with three numbered callout badges highlighting the key steps. Badge 1 marks Steam selected in the application list on the left, badge 2 highlights the "Erweitert" (Advanced) tab selected on the right panel, and badge 3 points to the checked option "Mit dedizierter Grafikkarte ausführen" ("Run with dedicated graphics card") — illustrating how to force Steam to launch on a dedicated GPU through the KDE graphical interface, as an alternative to manually editing the .desktop file.

Wenn ihr selbst eine Anwendung entwickeln wollt, die das für den Benutzer bereits übernimmt, genügt es, im entsprechenden Desktop-File PreferNonDefaultGPU=true zu setzen. Eure Anwendung wird dann auf den meisten Desktops automatisch auf eine dedizierte Grafikkarte ausgelagert, sofern eine vorhanden ist.

A screenshot of the Kate text editor on Linux, displaying the contents of the com.valvesoftware.Steam.desktop file — a desktop entry configuration file for the Steam Flatpak application. Two lines are highlighted with numbered red callout badges: badge 1 points to the [Desktop Entry] section header on line 1, and badge 2 highlights PrefersNonDefaultGPU=true on line 11, which is a key setting that instructs the system to run Steam on a dedicated GPU rather than the integrated one.

Für die Konsolen-Junkies unter euch: Ihr könnt auch diese Umgebungsvariablen setzen, dann startet eine Anwendung oder ein Spiel ebenfalls auf der dGPU: __NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia __VK_LAYER_NV_optimus=NVIDIA_only.

Das Setup und seine kleinen Schönheitsfehler

Das Setup funktionierte. Meistens. Bis die iGPU wieder beschloss, einfach zu sterben.

Ein typischer Tag sah so aus: Alles läuft. System stabil. Dann, ohne Vorwarnung: Freeze. Kein Mauszeiger, kein Tastatur-Input, gar nichts. Oder: Das System läuft nach einem Kernel-Update scheinbar problemlos, aber am nächsten Tag gibt es kein Videosignal mehr über HDMI. Einfach weg. Gerät vorhanden, Signal nicht.

AMD und die Mesa-Entwickler haben sich des Problems angenommen. Es gab Firmware-Updates von AMD, mit dem Ziel, die iGPU zu stabilisieren. Die entsprechenden Diskussionen und Patches könnt ihr in den Bugtrackern nachlesen:

Integrated AMD GPU randomly resets and crashes desktop - Bugzilla openSUSE

The system dies when watching HW accelerated YouTube videos in Firefox - Freedesktop Gitlab

Desktop freeze - amdgpu 0000:09:00.0: [drm] ERROR [CRTC:79:crtc-0] flip_done timed out - Freedesktop Gitlab

"The most common cause for page flip timeouts has been fixed in kernel 6.18.44, 7.1.8, and 7.2-rc7."

Die Firmware-Updates haben geholfen, zumindest sah es immer erst so aus. Das System lief stabil, bis es anfing, wieder dieselben Probleme zu verursachen, die dann immer häufiger auftraten. Da ich seit Jahren ein Rolling-Release nutze, bin ich zwangsläufig immer auf dem neuesten Kernel und der neuesten Firmware. Dennoch hat das, was in so vielen anderen Situationen einfach funktioniert hat, hier leider nicht geholfen.

Jetzt stellt euch mal vor, jemand mit einem Point-Release und einem älteren Kernel hat dieses Problem. Bis zum nächsten Distributionsupdate bleibt die iGPU schlicht unbenutzbar. Vielleicht auch im übernächsten Release noch. Und im darauffolgenden. Dann sind auch schon ein paar Jahre vergangen. Wenn selbst auf einem Rolling-Release dieses Problem seit mehr als zwei Jahren besteht, spricht das Bände.

Kleiner Einschub um meine Argumentation zu stützen, warum ich Point-Releases auf Desktop-Systemen ablehne. Weiteres dazu hier und hier.

NVIDIA schläft nicht

Während ich also meine Morgende damit verbracht habe, dmesg | grep -i amdgpu zu lesen wie andere Leute ihren Kaffee trinken, ist bei NVIDIA etwas Bemerkenswertes passiert: Die haben einfach ihren Treiber in Ordnung gebracht.

Explicit Sync? Unterstützt. Wayland-Stabilität? Deutlich verbessert. Tearing, Out-of-Order-Frames, die ganzen alten Probleme? Weitestgehend Geschichte. Ich nutze NVIDIA unter Linux mit Wayland seit mittlerweile über sechs Jahren, und es ist seit geraumer Zeit produktionstauglich. Gelegentliche Stolpersteine gab es, der Explicit-Sync-Kram war der schlimmste einer davon, aber das wurde behoben.

Und genau da liegt die bittere Ironie der Geschichte: Der ursprüngliche Grund, warum ich die iGPU überhaupt als primären Displayadapter einsetzen wollte, hat sich in Luft aufgelöst. NVIDIA hat das Problem auf ihrer Seite gelöst. Schneller, als AMD und Mesa die iGPU des 7800X3D in den Griff bekommen haben. Was deshalb besonders bemerkenswert ist, weil NVIDIA eigentlich dafür bekannt ist, sich mit Treiberreparaturen gerne sehr viel Zeit zu lassen.

Aktueller Stand: Aufgegeben (erstmal)

Nachdem ich die Nachricht im Bugtracker gelesen hatte, dass die gängigen Timeout-Probleme behoben sein sollten, habe ich direkt die iGPU im BIOS wieder aktiviert, die Monitore umgesteckt und getestet. Alles gut, erst einmal keine Timeouts. Da es aber schon spät war, wollte ich den Langzeittest auf den nächsten Tag verschieben. Am Morgen: kein Videosignal über HDMI. DisplayPort funktionierte problemlos, HDMI nicht.

Könnte auch mit jüngsten HDMI 2.1 enablement Patches seitens AMD zusammen hängen. Auch wenn diese erst für Linux Kernel 7.2 vorgesehen sind, welcher zum Zeitpunkt dieses Artikel noch nicht veröffentlicht wurde. Denn der Monitor wird erkannt, und auch Auflösung und unterstützte Bildwiederholrate werden mit im System angezeigt. Das Bild bleibt einfach nur leer. Der Monitor geh nicht in den Standby, sprich er bekommt irgend ein signal vom System. Nur eben keines mit Bild. Eine weitere Vermutung die sich mir aufdrängt ist, dass ich die iGPU sonst immer komplett deaktiviert habe, sie also vom System nicht einmal erkannt wird, als wäre das Gerät physikalisch nicht vorhanden. Da ich diese aber wieder aktiviert habe, kann es sein das eventuell Firmware für das Gerät nachgeladen wurde am Tag des ersten Tests, die nun auf dem Gerät ist.

Ich habe andere AMD-GPUs, darunter auch ähnliche integrierte Grafikchips, die nie auch nur ansatzweise solche Probleme gezeigt haben. Das führt mich zu einem unangenehmen Verdacht: Vielleicht, nur vielleicht, ist in meinem konkreten 7800X3D-Chip etwas defekt. Das wäre traurig, würde aber erklären, warum andere Systeme mit vergleichbarer Hardware keinerlei Probleme haben. Während ich hier sitze und Bugberichte lese wie andere Leute Netflix schauen.

Für alle, die ähnliche Probleme haben: Schaut euch die Kernel-Logs an, haltet Mesa aktuell und prüft, ob ihr die aktuelle AMD-Firmware installiert habt. Für den Rest gilt: Wenn ihr ein stabiles Wayland-Setup mit einer NVIDIA-Karte wollt, ist der aktuelle Treiber deutlich besser als sein Ruf aus vergangenen Jahren.

Zum Zeitpunkt dieses Artikels läuft bei mir NVIDIA-Treiber 595.84. Da frage ich mich, was openSUSE macht, und wo der am 3. August veröffentlichte Treiber 595.91.07 bleibt.

A "Latest Revision" panel from a software repository interface, showing the most recent commit to a package. It displays that user Stefan Dirsch (sndirsch) committed revision 30 eight days ago, with the commit message "update version to 595.91.07 (boo#1271601)", along with two action links — "Files Changed" and "Browse Source" — on the bottom right.

Vor 8 Tagen veröffentlicht, noch nicht in den Repos gelandet. Na, dann wird es ja die Tage soweit sein.

Ich verlasse mich vorerst wieder vollständig auf NVIDIA. Und das Seltsamste daran ist: Es funktioniert einfach. Hingegen der allgemeinen Meinung wenn es um Grafikkarten und Linux geht.