Startseite / Tech
Tech

Linux 7.5 behebt alten Video-Bug bei Radeon HD 2000 und 3000

Linux 7.5 behebt alten Video-Bug bei Radeon HD 2000 und 3000
← Alle Beiträge

Fast zwei Jahrzehnte nach der Markteinführung erhält ein Teil der AMD-Grafikkarten aus den Serien Radeon HD 2000 und HD 3000 einen Linux-Fix für fehlerhafte Videowiedergabe. Ein bereits angenommener Kernel-Patch soll mit Linux 7.5 ausgeliefert werden. Er beseitigt Bildstörungen, die bei hardwarebeschleunigter Videodekodierung zusammen mit aktiver Desktop- oder 3D-Darstellung auftreten konnten.

Betroffen ist der Unified Video Decoder, kurz UVD, auf den Chipfamilien RV610, RV620, RV630, RV635 und RV670. Die Ursache lag nicht im Videomaterial und auch nicht in mangelnder Rechenleistung. Der Linux-Treiber hielt die Eingabepuffer des Decoders nicht zuverlässig im dedizierten Grafikspeicher. Der Patch erzwingt nun genau diese Platzierung.

Für Nutzer ist damit vor allem eine Einschränkung wichtig: Die Korrektur betrifft alte Rechner, auf denen eine passende Radeon-GPU unter Linux tatsächlich zur Hardwaredekodierung verwendet wird. Sie macht die Karten weder schneller noch erweitert sie deren Codec-Unterstützung. Sie beseitigt einen konkreten Fehler in einem inzwischen seltenen, aber weiterhin genutzten Treiberpfad.

Betroffen ist nicht jede Radeon HD 2000

Die Radeon-HD-2000-Reihe kam 2007 auf den Markt. Sie war AMDs erste Desktop-GPU-Serie nach der Übernahme von ATI und markierte den Wechsel von getrennten Pixel- und Vertex-Einheiten zu einer Unified-Shader-Architektur. UVD ergänzte diese Grafikarchitektur um einen eigenen Hardwareblock für die Dekodierung von Video, insbesondere für H.264 und VC-1. Das war damals vor allem für Heimkino-PCs relevant, deren Prozessoren hochauflösendes Video nicht immer ohne Hilfe flüssig abspielen konnten.

Die breite Bezeichnung Radeon HD 2000 darf allerdings nicht darüber hinwegtäuschen, dass nicht jedes Modell denselben Videoblock besitzt. UVD ist unter anderem in den GPUs der Radeon HD 2400 und HD 2600 integriert. Die Radeon HD 2900 hat dagegen keinen UVD-Kern und beschleunigte Video über ihre Shader. Der neue Patch ist deshalb kein pauschaler Fix für sämtliche Karten, die unter dem Namen HD 2000 verkauft wurden.

Zur betroffenen Gruppe gehören außerdem Chips der Radeon-HD-3000-Familie. Entscheidend ist nicht allein der Verkaufsname auf der Karte, sondern der verbaute Chip und die Nutzung des alten Radeon-Kerneltreibers samt UVD-Pfad.

Der Fehler saß in der Speicherplatzierung

Beim hardwarebeschleunigten Abspielen werden komprimierte Videodaten über Eingabepuffer an den UVD-Block übergeben. Der bisherige Treibercode stellte nicht durchgehend sicher, dass diese Puffer im lokalen VRAM verblieben. Sobald die GPU parallel den Desktop zeichnete oder eine 3D-Aufgabe bearbeitete, konnte die fehlerhafte Speicherplatzierung zu sichtbarer Korruption im Videobild führen.

Warum der UVD-Patch die Bildfehler beseitigt
Speicherplatzierung entscheidet über das VideobildHardware-Decodingplus GrafiklastBisherUVD-Puffer nichtfest im VRAMBildfehlerPatch für Linux 7.5UVD-Puffer bleibenim VRAMSaubere Wiedergabe
Die Grafik zeigt, wie die Platzierung der UVD-Eingabepuffer bei gleichzeitiger Grafiklast zu Bildfehlern führte und wie der Linux-7.5-Patch die Puffer im VRAM hält.

Die Korrektur ist konzeptionell überschaubar: Die UVD-Eingabepuffer werden im Grafikspeicher fixiert. Der Radeon-Treiber setzte dieses Verhalten für mehrere andere Chipfamilien bereits durch. Nun wird es auch auf den betroffenen R600-Varianten angewandt. Gerade dieser Vergleich mit den vorhandenen Sonderbehandlungen im Treiber half dabei, die Abweichung im alten Codepfad zu erkennen.

Der Fall zeigt eine typische Schwierigkeit bei Legacy-Treibern. Der Defekt muss nicht ständig auftreten, sondern erst unter einer bestimmten Kombination aus Hardwaredekodierung, Speichernutzung und gleichzeitiger Grafiklast. Ein Video kann daher zunächst korrekt laufen und erst bei weiteren Aktivitäten auf dem Desktop sichtbare Fehler produzieren. Solche Bedingungen erschweren reproduzierbare Tests und erklären, warum ein Fehler trotz offenen Quellcodes über viele Jahre bestehen kann.

Der Patch wirkt erst mit dem passenden Kernel

Entwickelt wurde die Korrektur vom Open-Source-Beitragenden Ted Bullock. Der Patch ist angenommen und für Linux 7.5 vorgesehen. Praktisch profitieren Nutzer daher erst, wenn sie einen Kernel mit dieser Änderung installieren. Distributionen könnten den Patch grundsätzlich in ältere Kernel zurückportieren; ob und wo das geschieht, ist bislang nicht angegeben.

Wer einen betroffenen Rechner betreibt, muss deshalb nicht die Grafikkarte austauschen, sondern zunächst den tatsächlich verwendeten Kernel und den aktiven Videodekoder prüfen. Läuft die Wiedergabe ausschließlich über die CPU, verändert der Patch nichts. Wird UVD verwendet und treten unter paralleler Desktop- oder 3D-Last Bildfehler auf, adressiert Linux 7.5 genau diesen Fall.

Auch nach dem Update bleiben die grundsätzlichen Grenzen der fast 20 Jahre alten Hardware bestehen. Der Fix liefert keine Unterstützung für zusätzliche Videoformate, senkt nicht den Energieverbrauch und ändert nichts an der geringen Leistung im Vergleich zu heutigen integrierten Grafiklösungen. Er kann aber bestehende HTPCs, Retro-Systeme und ältere Desktop-Rechner für ihren bisherigen Zweck zuverlässiger machen.

Codex half bei der Suche, ersetzte aber nicht den Kernel-Prozess

Bullock setzte OpenAIs Codex ein, um den veralteten Treiberpfad zu untersuchen, Tests zu unterstützen und den Patch zu erstellen. Das ist bemerkenswert, weil die Arbeit an alten Grafiktreibern oft an fehlender Dokumentation, selten gewordener Testhardware und komplexen Wechselwirkungen mit der Speicherverwaltung hängt.

Die belastbare Aussage lautet dennoch nicht, dass eine KI den Fehler selbstständig behoben hat. Ein Beitragender nutzte Codex als Werkzeug; anschließend musste die Änderung als normaler Kernel-Patch nachvollziehbar sein und akzeptiert werden. Für die Wartung alter Software ist genau diese Arbeitsteilung interessanter als die Vorstellung einer automatischen Reparatur: Ein Werkzeug kann Such- und Analyseaufwand reduzieren, während Tests, Review und Verantwortung im etablierten Entwicklungsprozess bleiben.

Offener Code verlängert den Wartungszeitraum

AMD pflegt die R600-GPUs seit Jahren nicht mehr offiziell. Trotzdem kann eine Korrektur in den aktuellen Linux-Kernel gelangen, weil der relevante Treibercode offenliegt und unabhängige Entwickler Änderungen einreichen können. Das garantiert keine vollständige oder zeitnahe Unterstützung alter Hardware. Es schafft aber überhaupt erst die Möglichkeit, einen wirtschaftlich uninteressanten Nischenfehler lange nach dem Ende des Hersteller-Supports zu beheben.

Der entscheidende Mechanismus hinter dieser Meldung ist daher nicht das Alter der Grafikkarten und auch nicht Codex allein. Ausschlaggebend ist, dass ein reproduzierbarer Fehler auf einen weiterhin zugänglichen Codepfad trifft und jemand die verbleibende Hardware noch testen kann. Bei Legacy-Systemen ist diese Kombination häufig knapper als die Rechenleistung: Ohne Quellcode, Testgerät und einen überprüfbaren Patch bleibt selbst ein kleiner Fehler dauerhaft bestehen.

J

Über den Autor

Jens Könnig

Jens analysiert seit Jahren digitale Märkte, Preisbewegungen und Plattform-Strategien. Als Betreiber mehrerer datengetriebener Systeme wertet er täglich große Mengen an Produkt- und Trenddaten aus. Sein Fokus liegt auf Einordnung statt Hype: Was bedeutet eine Entwicklung wirklich für Nutzer, Preise und Märkte?

Alle Artikel von Jens Könnig →