Als AMD im Zuge der Vorstellung seiner RDNA4-Grafikprozessoren FidelityFX Super Resolution 4 (FSR4) ankündigte, löste dies in der Gaming-Community viel Aufsehen aus. FSR4 verspricht nicht nur eine beeindruckend gesteigerte Bildqualität im Vergleich zum Vorgänger FSR 3.1, sondern setzt auch als erste FSR-Version auf maschinelles Lernen für die Bildverbesserung anstelle traditioneller analytischer Methoden. Für Linux-Spieler stellt die Aktivierung von FSR4 eine besonders große Herausforderung dar, da die Technologie offiziell noch nicht für Entwickler freigegeben ist und deren Nutzung bislang weitgehend vom AMD-Treiber in Windows dominiert wird. Dennoch wächst der Druck seitens der Linux-Community, FSR4 auch unter Linux lauffähig zu machen – aus gutem Grund, denn ohne diese Funktionalität könnte der Kauf einer RDNA4-Grafikkarte in einem Linux-Systemumfeld deutlich an Attraktivität verlieren.
Der erste Hinderungsgrund liegt darin, dass FSR4 offiziell aktuell über kein öffentlich zugängliches SDK verfügt und nicht direkt in Spiele oder Engines integriert werden kann. Stattdessen wird die Funktionalität über Treiberumgehungen und DLLs realisiert, die von Spielen, welche für FSR 3.1 entwickelt wurden, aufgerufen und durch FSR4 ersetzt werden können. Dabei agiert die FSR 3.1-Implementierung als eine Art Proxy, der überprüft, ob FSR4 im AMD-Kontrollzentrum aktiviert ist und bei Freigabe die Kontrolle an eine proprietäre DLL namens amdxcffx64.
dll übergibt, welche die neue Upscaling-Technologie tatsächlich ausführt. Diese DLL wiederum kommuniziert mit der eigentlichen Treiber-DLL amdxc64.dll und nutzt eine Reihe von undokumentierten, proprietären Shaderbefehlen, um die komplexen WMMA-Matrizenoperationen (Wave Matrix Multiply Accumulate) auszuführen – eine wesentliche Grundlage für die maschinellen Lernverfahren hinter FSR4. Die interne Arbeitsweise von FSR4 basiert demnach auf komplexen D3D12-Compute-Shadern, die mit einer großen Anzahl von geheimen, nicht öffentlich dokumentierten AMD-spezifischen Assembler-Operationen angereichert sind. Diese OpCodes werden in Form miteinander verketteter atomarer Compare-and-Exchange-Operationen verschlüsselt und sind für das direkte Verständnis und die Analyse ohne Reverse Engineering nahezu undurchschaubar.
Im Gegensatz zu DLSS von Nvidia, das stärker auf proprietäre CUDA-Technologie angewiesen ist, ermöglicht diese Architektur zumindest den Ansatz, mit großer Beharrlichkeit und technischem Verständnis zumindest eine Nachbildung oder Emulation unter Linux zu entwickeln. Eine der bedeutendsten Herausforderungen war die Zuordnung und das Verständnis dieser WMMA-Operationen in Verbindung mit Vulkan. Zum Glück existiert mit der Vulkan-Erweiterung VK_KHR_cooperative_matrix eine Schnittstelle, die genau solche Matrix-Multiplikations- und Akkumulationsfunktionen unterstützt und damit Zugang zu den entsprechenden Hardwaretechnologien auf RDNA3- und RDNA4-GPUs gewährt. Allerdings fehlt im DirectX-Ökosystem eine vollständige Umsetzung dieser Funktionalität, was den Nachbau von FSR4 komplizierter macht. Um einen tieferen Einblick in die Substanz von FSR4 zu erhalten, wurden Shader im populären Spiel Ratchet & Clank – Rift Apart untersucht, das offiziell FSR4 unterstützt.
Dort konnten über Tools wie Render Doc und AMDs Radeon GPU Profiler WMMA-Befehle und die damit verbundenen Shader-Programme identifiziert und extrahiert werden. Diese Analyse lieferte wertvolle Daten darüber, wie FSR4 die eigentlichen Bildverbesserungen berechnet und welche Shaderphasen entscheidend sind. Anschließend wurde das problematische Verhalten des Treibers in Bezug auf Debugging-Tools erkannt: Sobald RenderDoc oder andere Debugging-Werkzeuge an die GPU-Shader anbandelten, blockierte der AMD-Treiber den Einsatz von FSR4. Dies erforderte eine kreative Vorgehensweise, indem einfach ein existierendes FSR3.1-Demo umbenannt wurde, um die Anwendung als RiftApart.
exe erscheinen zu lassen. So konnten Shaderdaten „gefangen“ und weiterverarbeitet werden – ein Beweis für die Entschlossenheit und das technische Geschick der Entwickler in der Linux-Community. Neben der Entschlüsselung der Opcode-Ströme und der Matrix-Datenformate musste auch die exakte Umsetzung von FP8-Mathematik auf Vulkan-Ebene nachgebildet werden. FP8 (auch als E4M3 bekannt) ist eine 8-bit Gleitkommazahl mit 4 Bit Exponent und 3 Bit Mantisse, welche besonders sparsam im Speicher ist und auf RDNA4 exklusiv implementiert wird. Vulkan und SPIR-V unterstützen FP8 bislang nicht nativ, was zu einer aufwendigen Emulation führte.
Dabei wurden Bit-Manipulationen und Tricks angewandt, um FP8-Daten in FP16 umzuwandeln und korrekt zu verarbeiten. Die Ausführung von FP8-Berechnungen auf GPUs ohne nativen Support ist eine künstlerische Mischung aus Performance-Optimierung und Kompromissen hinsichtlich Genauigkeit und der Komplexität der Shaderinstruktionen. Darüber hinaus gestaltete sich die korrekte Implementierung und Handhabung von lokalen Datenspeichern (LDS) in den Shadern als erhebliche Herausforderung. Die teilweise fehlerhaften FSR4-Shader im Originalcode gingen von einer fixen LDS-Größe von 256 Byte aus, obwohl in der Praxis 512 Byte benötigt werden. AMDs Treiber kompensiert dieses Problem nur durch großzügige Speicherallokation, während die Implementierung unter Vulkan und Open-Source-Treibern wie RADV manuell mit Workarounds über Padding behandelt werden musste.
Ohne diese Korrektur kam es zu Datenüberschreibungen und Renderfehlern. Ein weiterer kritischer Punkt betraf die Performance. Native Windows-Implementierungen von FSR4 auf einer Radeon RX 7900 XT erreichen beeindruckende Verarbeitungsgeschwindigkeiten von unter 1 Millisekunde bei 1440p. Die frühen Linux-Versionen unter Verwendung von vkd3d-proton und dem Vulkan-RADV-Treiber waren bei der gleichen Auflösung deutlich langsamer und erreichten lediglich etwa 3 Millisekunden, was für Echtzeitanwendungen suboptimal ist. Eine tiefe Integration und Optimierung auf Treiber- und Shader-Ebene ist hier erforderlich, um mehr Effizienz herauszuholen.
Der Open-Source-Treiber RADV, der auf AMD-GPUs unter Vulkan eingesetzt wird, konnte durch experimentelle Erweiterungen bereits grundlegenden Support für FP8 sowie Gewinnung von besserer Leistung demonstrieren. Allerdings benötigt die gesamte Pipeline präzise Unterstützung neuer Shader-Features und eine exakte Umsetzung der komplexen WMMA-Operationen im Vulkan-Kontext. Um diese Ziele zu erreichen, wurde im Rahmen von dxil-spirv (einem Shader-Translator von D3D12-DXIL zu SPIR-V) umfangreiche Unterstützung für die undokumentierten AGS-Opcode-Systeme hinzugefügt. Das Verfahren ist eine besondere Herausforderung aufgrund der hybride Shader-Pipeline zwischen Windows D3D12 und Vulkan im Linux-Subsystem Proton, auf die FSR4 letztlich angewiesen ist. Für GPUs der vorherigen Generation, etwa RDNA3, ist der Einsatz von FSR4 noch schwieriger.
RDNA3 unterstützt zwar WMMA, allerdings nur im FP16-Format und ohne FP8-Fähigkeiten. Die Emulation von FP8 FSR4-Funktionalität sorgte zwar für eine gewisse Kompatibilität, führte aber zu unbefriedigenden Performance-Ergebnissen. Zudem treten auf RDNA3-Prozessoren weitere Komplikationen durch unterschiedliche geltende Matrix-Layouts und Subgruppen-Strukturen auf, die zu fehlerhaften Darstellungen führen können. Durch komplizierte Workarounds und Anpassungen der Shaderlogik konnten solche Probleme zwar teilweise abgefedert werden, die Praktikabilität bleibt wegen der massiven Leistungseinbußen allerdings eingeschränkt. Das engagierte Engagement der Linux-Gemeinschaft, die Zusammenarbeit von erfahrenen Entwicklern, Reverse Engineern und Grafikexperten haben FSR4 auf Linux-Plattformen erstmals zum Laufen gebracht.
Dieses Meisterwerk würde ohne Offenheit, Geduld und die Bereitschaft, tief in Shader-Assemblersprache und Treibermechanismen einzutauchen, kaum möglich gewesen sein. Auch wenn die Verfügbarkeit in der Praxis noch nicht erreicht ist, wächst die Grundlage für eine künftige offizielle Integration stetig. Die Entwicklung zeigt eindrucksvoll, wie viel komplexe Innovation hinter modernen Upscaling-Techniken steht und welche Herausforderungen eröffnet sich, wenn proprietäre Technologien plattformübergreifend funktionieren sollen. FSR4 stellt einen Meilenstein in der visuellen Qualität dar, der gerade für Linux-Spieler einen bedeutenden Fortschritt markiert. Mit entsprechender Weiterentwicklung des Vulkan-Ökosystems, der Unterstützung von FP8 und neuer Shadererweiterungen im Treiberumfeld kann in naher Zukunft die volle Leistungsfähigkeit des Machine Learning Upscaling auch unter Linux ausgeschöpft werden.
Abschließend bleibt zu sagen, dass der technische Aufwand und die Community-getriebene Ingenieurskunst rund um FidelityFX FSR4 ein beeindruckendes Beispiel moderner Grafikprogrammierung und plattformübergreifender Gaming-Verbesserung sind. Die Unterstützung für neue Hardware-Funktionalitäten wie WMMA, die Emulation neuer Datenformate und die Integration proprietärer Shader-Mechanismen in freie Grafikstapel zeigen, welchen Stellenwert das Thema Bildqualität im aktuellen Gaming- und Grafikmarkt hat – über Betriebssystemgrenzen hinweg. Die Reise von FSR4 auf Linux ist eine Geschichte von Hartnäckigkeit, technischem Können und der Vision, jedem Spieler atemberaubend schöne Grafikdarstellung zu ermöglichen.
