RADV auf Windows: Valves ungewöhnlicher Treiber-Sprung

Ein Grafiktreiber, der seit Jahren tief im Linux-Kernel verwurzelt ist, soll künftig auch unter Windows laufen – und ausgerechnet Valve zahlt dafür die Rechnung. Was nach einer Randnotiz aus der Open-Source-Szene klingt, ist in Wahrheit ein ziemlich unbequemer Schritt für einen Konzern, der sein gesamtes Gaming-Geschäft auf Linux aufgebaut hat. Der Grund ist banal: Wenn RADV auf Windows laufen soll, kann Valve die Regeln des eigenen Ökosystems nicht mehr diktieren. Genau das haben Collabora-Entwickler jetzt öffentlich gemacht, und genau deshalb lohnt sich ein technischer Blick unter die Motorhaube.

RADV auf Windows: Was Valve und Collabora tatsächlich vorhaben

Der Softwaredienstleister Collabora hat am 28. Juli 2026 in einem technischen Blogbeitrag zur Portierung von RADV auf Win32 die ersten konkreten Schritte einer von Valve gesponserten Portierung beschrieben. Autor Louis-Francis Ratté-Boulianne umreißt darin, wie weit das Team bereits gekommen ist – und wie viel Fleißarbeit noch fehlt. Wichtig für die Einordnung: Es handelt sich explizit um eine frühe, explorative Phase, kein fertiges Produkt und keine offizielle Roadmap mit Datum.

RADV ist der freie Vulkan-Treiber für AMD-Grafikkarten aus dem Mesa-Projekt, entwickelt von Valve-Mitarbeitenden und der Community gemeinsam. Er sitzt unter Linux direkt zwischen Spiel und Grafikhardware und ist einer der Gründe, warum Steam Deck und andere AMD-basierte Linux-Systeme überhaupt konkurrenzfähige Bildraten liefern. Ohne RADV müsste Proton – die Kompatibilitätsschicht für Windows-Spiele unter Linux – auf deutlich langsamere Software-Fallbacks zurückgreifen. Die Ironie der aktuellen Meldung: Jetzt soll derselbe Treiber den umgekehrten Weg gehen und unter Windows funktionieren.

Berichterstattung dazu lieferte am selben Tag auch Phoronix in einer unabhängigen Einordnung des Vorhabens. Beide Quellen decken sich in einem zentralen Punkt: Es geht Valve nicht darum, RADV als Ersatz für AMDs offizielle Windows-Treiber zu positionieren. Es geht um Testinfrastruktur, Debugging und die Möglichkeit, Vulkan-Verhalten zwischen beiden Betriebssystemen direkt zu vergleichen.

Warum der Linux-Kernel-Treiber tabu bleibt

Der technisch spannendste – und zugleich unbequemste – Teil der Geschichte ist, was nicht portiert wird. AMDGPU, der Linux-Kernel-Treiber, der RADV normalerweise mit der Hardware verdrahtet, bleibt außen vor. Eine Portierung des kompletten Kernel-Treibers nach Windows wäre ein Mammutprojekt und würde tief in AMDs eigenes Terrain eingreifen. Stattdessen setzt das Collabora-Team auf einen deutlich pragmatischeren Ansatz: RADV soll unter Windows auf den offiziellen, proprietären AMD-Kernel-Treiber aufsetzen, der ohnehin auf jedem Windows-System mit Radeon-Grafikkarte läuft.

Klingt einfach, ist es aber nicht. Der AMD-Windows-Kerneltreiber spricht ein anderes internes Protokoll als das, was RADV unter Linux erwartet – schlicht, weil er nicht für Mesa gebaut wurde. Die Collabora-Ingenieure müssen deshalb Teile der internen Datenstrukturen des proprietären Treibers durch Reverse Engineering nachvollziehen, um RADV die nötigen Kommandos in einer Form zu liefern, die der Windows-Treiber versteht. Das ist mühsam, teilweise unsicher, und garantiert nicht, dass jede AMD-Generation gleich gut funktioniert.

Für Admins und Entwicklerinnen, die schon einmal mit Lizenzblockaden im Linux-Grafikstack rund um DRM und KMS zu tun hatten, klingt dieses Muster vertraut: Offene Software, die an eine geschlossene Schnittstelle andockt, ist immer ein Balanceakt zwischen Funktionalität und Wartbarkeit. Jede neue AMD-Treiberversion unter Windows kann die internen Strukturen ändern und die Reverse-Engineering-Arbeit teilweise wieder zunichtemachen. Das ist kein Beinbruch, aber ein laufender Wartungsaufwand, den man bei einem „einfachen Port“ gern unterschätzt.

Windows WDDM2, das Grafiktreibermodell des Betriebssystems, bringt zusätzlich eigene Eigenheiten mit, die unter Linux schlicht nicht existieren. Speicherverwaltung, Synchronisationsprimitive und der Umgang mit mehreren GPU-Kontexten funktionieren anders als im Direct Rendering Manager von Linux. Wer sich mit dem Remote-Desktop-Protokollstack unter Linux beschäftigt hat, kennt ähnliche Reibungspunkte beim Übersetzen zwischen zwei grundverschiedenen Systemarchitekturen – nur dass es hier nicht um Fernzugriff, sondern um Millisekunden bei der Bildausgabe geht.

Ähnliche Wege: Wie andere Übersetzungsschichten den Sprung zwischen Systemen schaffen

Ganz neu ist die Idee, Grafiktechnik zwischen Windows und Linux hin- und herzuschieben, ohnehin nicht – nur die Richtung ist ungewöhnlich. Unter Proton übersetzt etwa DXVK DirectX-9-bis-11-Aufrufe in Vulkan-Befehle, VKD3D erledigt das Gleiche für DirectX 12. Beide Projekte laufen unter Linux und erlauben es, Windows-Spiele ohne native Linux-Version flüssig darzustellen. Zink geht den umgekehrten Weg innerhalb der offenen Welt: Es übersetzt ältere OpenGL-Aufrufe in Vulkan, damit Treiberteams nicht zwei komplette Backends parallel pflegen müssen. Das RADV-Windows-Experiment reiht sich in diese Tradition von Übersetzungsschichten ein, dreht die gewohnte Richtung aber um 180 Grad.

Der Unterschied zu DXVK oder VKD3D ist trotzdem fundamental: Dort übersetzt man zwischen zwei Grafik-APIs auf demselben Betriebssystem. Bei RADV unter Windows übersetzt man denselben Treiber zwischen zwei völlig unterschiedlichen Kernel-Architekturen – Linux mit seinem offenen DRM-Subsystem auf der einen, Windows mit dem geschlossenen WDDM2-Modell auf der anderen Seite. Das ist technisch näher an Projekten wie Wine, das komplette Windows-APIs unter Linux nachbaut, nur eben spiegelverkehrt und auf die Grafikschicht beschränkt. Wer sich mit der Geschichte solcher Kompatibilitätsprojekte beschäftigt, merkt schnell: Die erfolgreichsten laufen selten schnell, sondern über Jahre iterativer Kleinarbeit, oft finanziert von einem einzigen zahlungskräftigen Sponsor mit klarem Eigeninteresse.

Genau das ist bei RADV nicht anders. Valve hat weder bei Proton noch bei früheren Mesa-Investitionen auf schnelle Ergebnisse gesetzt, sondern auf einen langen Atem, der sich erst nach mehreren Jahren produktiv auszahlte. Wer die aktuelle Meldung also als kurzfristigen Produktankündigung liest, verpasst den eigentlichen Punkt: Es ist ein weiterer Baustein in einer Strategie, die Valve seit dem ersten Steam-Deck-Prototyp konsequent verfolgt – so viel wie möglich von der eigenen Grafikschicht selbst kontrollieren, statt sich allein auf Herstellertreiber zu verlassen.

Was für Steam Deck, Proton und Linux-Gaming auf dem Spiel steht

Die naheliegende Frage: Bringt das RADV-Windows-Experiment dem Steam Deck oder Proton irgendetwas? Kurzfristig: nein, direkt nicht. Das Steam Deck läuft unter SteamOS, also Linux, und wird das auch bleiben. Was sich aber ändert, ist die Testbarkeit des Treibers selbst. Wenn Entwickelnde RADV parallel unter Windows und Linux mit identischer Hardware laufen lassen können, wird es erheblich leichter, Bugs von Plattformeigenheiten zu unterscheiden. Verhält sich ein Rendering-Fehler auf beiden Systemen gleich, liegt das Problem im Treibercode selbst. Tritt er nur unter Windows auf, deutet das auf die WDDM2-Integrationsschicht hin.

Diese Trennschärfe ist für ein Open-Source-Projekt wie Mesa Gold. Aktuell müssen RADV-Entwicklerinnen bei kniffligen Rendering-Bugs häufig raten, ob ein Problem plattformspezifisch ist – jetzt bekommen sie ein Vergleichswerkzeug. Die offizielle Mesa-Dokumentation zum RADV-Treiber beschreibt bereits heute die enorme Bandbreite an unterstützter Hardware, von älteren GCN-Generationen bis zu aktuellen RDNA-Chips. Ein zusätzlicher Windows-Testpfad würde diese Kompatibilitätsmatrix zusätzlich absichern, ohne dass Valve dafür ein zweites, komplett getrenntes Treiberprojekt aufbauen müsste.

Interessant wird es auch für Studios, die Spiele parallel für Windows und Linux/Steam Deck ausliefern. Wer heute testen will, ob ein Shader-Problem am Treiber oder am eigenen Code liegt, braucht im Zweifel zwei komplett unterschiedliche Toolchains. Ein RADV-Build, der unter Windows läuft, würde diese Lücke schließen – zumindest für Studios, die ohnehin schon mit dem offenen Treiber statt AMDs proprietärem Windows-Pfad experimentieren wollen. Das bleibt vorerst ein Nischenpublikum, aber genau aus solchen Nischen sind Steam Deck und Proton selbst einmal gestartet.

Was das für Admins und Entwicklerinnen praktisch bedeutet

Wer im eigenen Unternehmen mit gemischten Grafikumgebungen arbeitet – etwa CI-Runner mit AMD-GPUs, die sowohl Windows- als auch Linux-Builds testen – sollte diese Entwicklung im Blick behalten, aber noch nicht produktiv einplanen. Der Code steckt in einer frühen, experimentellen Phase, es gibt kein Release, keine Paketquelle und keine Garantie auf Stabilität. Wer jetzt neugierig ist, findet die Arbeit öffentlich in den einschlägigen Mesa-Repositories, allerdings ohne fertige Build-Anleitung für Endanwendende.

Praktisch heißt das für Terminal-nahe Arbeit: Wer bereits mit Firmware- und Treiberupdates unter Linux jongliert, kennt das Muster, dass offene Treiberprojekte oft Monate vor einem stabilen Release schon öffentlich diskutiert werden. Das ist kein Zufall, sondern gelebte Open-Source-Praxis: Wer früh mitliest, kann früh Bugs melden, bevor sie in einem Release landen. Für IT-Abteilungen mit Linux-Workstations auf AMD-Basis lohnt sich also ein Blick auf die Collabora-Blogreihe, aber ohne Hektik.

Ein Nebenaspekt, der in der Debatte gern untergeht: Valve finanziert seit Jahren einen erheblichen Teil der Linux-Grafik-Infrastruktur, von Mesa über Wine bis zu Kernel-Beiträgen. Diese Investition zahlt sich doppelt aus – für das eigene Steam-Deck-Geschäft, aber auch für die gesamte Linux-Desktop-Community, die von besseren Treibern profitiert, ohne selbst einen Cent dafür auszugeben. Wer sich fragt, warum ein Gaming-Konzern plötzlich Windows-Portierungsarbeit an einem Linux-Treiber finanziert, findet die Antwort also nicht in Marktanteilen, sondern in Testinfrastruktur und Entwicklergeschwindigkeit.

Wie robust das Ganze am Ende wird, hängt stark davon ab, wie viel Reverse-Engineering-Arbeit AMDs proprietärer Windows-Treiber in Zukunft noch zulässt. Ändert AMD seine internen Schnittstellen radikal, könnte die gesamte Windows-Portierung von RADV mehrfach neu aufgesetzt werden müssen. Genau deshalb betonen sowohl Collabora als auch die begleitende Berichterstattung, dass es sich um ein Forschungsprojekt handelt – nicht um ein Produkt mit Versprechen.

Wer selbst experimentieren möchte, sollte nicht auf ein fertiges Installationspaket warten, sondern die Mesa-Quellen direkt beobachten. Praktisch bedeutet das: Merge Requests im offiziellen Mesa-Repository verfolgen, insbesondere alles, was sich um Win32-Backends und WDDM2-Integration dreht. Für IT-Teams, die ohnehin schon eigene Build-Pipelines für Grafiktreiber pflegen, ist das ein guter Zeitpunkt, testweise einen separaten Zweig anzulegen und die Kompilierbarkeit unter Windows mitzuverfolgen – nicht produktiv, aber als Frühwarnsystem für spätere, stabilere Versionen. Wer schon einmal einen Kernel-Treiber selbst gebaut hat, weiß: Genau in dieser frühen, unglamourösen Phase entscheidet sich, ob ein Projekt später zuverlässig läuft oder in ein Wartungsloch fällt.

Für den administrativen Alltag heißt das konkret: Noch keine Produktionssysteme umstellen, aber Monitoring-Skripte und Testumgebungen so vorbereiten, dass ein Wechsel später ohne größere Umbauten möglich ist. Wer Grafiklast unter Linux und Windows ohnehin schon getrennt misst, etwa über eigene Vulkan-Benchmarks oder GPU-Profiler, kann diese Werkzeuge später eins zu eins auf den experimentellen RADV-Windows-Pfad anwenden. Das kostet heute nur wenig Vorbereitungszeit, spart aber später eine hektische Nachrüstung, sollte sich das Projekt schneller entwickeln als erwartet.

Und jetzt?

Der Reiz an dieser Geschichte liegt nicht in einem fertigen Ergebnis, sondern im Prinzip dahinter: Ein offener Treiber, der jahrelang als Linux-exklusives Vorzeigeprojekt galt, wagt sich testweise auf fremdes Terrain – ganz ohne den Anspruch, dort jemals die Standardlösung zu werden. Für Linux-Gaming ändert sich kurzfristig nichts, für die Qualität von RADV mittelfristig möglicherweise einiges. Wer selbst mit AMD-Grafikkarten unter Linux oder Windows arbeitet, kann die Entwicklung in den offiziellen Mesa-Kanälen weiterverfolgen. Spannend wird, ob AMD dieses Experiment als Bedrohung oder als kostenlose Qualitätssicherung für die eigene Treiberschnittstelle begreift.