Spielen unter Linux: Raytracing dank Vulkan-Erweiterung noch effizienter
Die Khronos Group hat Vulkan 1.4.351 mit sechs neuen Erweiterungen veröffentlicht. Das Highlight für Spieler ist ganz sicher die sogenannte "Opacity Micromap", eine Erweiterung für effizienteres Raytracing, doch das ist längst nicht alles.
Die Khronos Group hat am 8. Mai 2026 heimlich, still und leise sein neuestes Spezifikations-Update auf Vulkan 1.4.351 veröffentlicht. Wie Phoronix berichtet, bringt das Update gleich sechs neue Erweiterungen mit, von denen insbesondere eine für alle Linux-Spieler, Proton-Nutzer und alle, die auf quelloffene Grafik-APIs setzen, von unmittelbarer Relevanz ist: VK_KHR_Opacity_Micromap eine lang ersehnte Verbesserung für die Raytracing-Beschleunigung unter Vulkan.
Opacity Micromap bringt effizienteres Raytracing
Die wichtigste der sechs neuen Erweiterungen ist ohne Frage VK_KHR_Opacity_Micromap und diese ist insbesondere für Linux-Spieler interessant. Die Extension verbessert die Raytracing-Beschleunigung unter Vulkan, indem Entwickler die Möglichkeit erhalten, einer Geometrie beim Aufbau einer entsprechenden Beschleunigungsstruktur eine sogenannte Opacity Micromap hinzuzufügen. Doch was bedeutet das konkret?
Quelle: Khronos Group
Bislang mussten Entwickler bei transparenter Geometrie in Raytracing-Szenen entweder die Geometrie stärker unterteilen, was mehr Grafikspeicher kostet, oder aber einen sogenannten Any-Hit-Shader während des Ray-Traversals aufrufen, was zur Laufzeit mitunter deutlich an Rechenleistung kosten kann. Hier setzt diese Erweiterung entsprechend an:
- Opacity Micromaps codieren Transparenzinformationen in einem kompakten Format, welches die Implementierung nutzen kann, um die Teile von Dreiecken entsprechend als lichtundurchlässig ("opak"), transparent oder als möglichen Treffer zu markieren.
- Das komprimierte Format unterteilt jedes Dreieck in eine Menge von Teildreiecken, von denen jedem dann entweder zwei oder vier Opazitätswerte zugewiesen werden können. Diese Werte steuern, ob ein Strahl, der dieses Teildreieck trifft, als opaker Treffer, vollständiger Fehlschlag oder möglicher Treffer behandelt wird.
Für Linux-Spieler ist besonders relevant: Nvidia hat VK_KHR_Opacity_Micromap bereits in seinem Beta-Treiber 595.44.07 gelistet. Eine Unterstützung auf Treiberebene, welche zeigt, dass die Erweiterung nicht nur auf dem Papier existiert, sondern zeitnah in der Praxis ankommen soll. Dass Nvidia so früh reagiert, ist ein sehr gutes Zeichen.
Vulkan als Schlüssel für Proton und Wine
Da Proton und Wine unter Linux vollständig auf Vulkan als Übersetzungsschicht aufbauen, profitieren alle Spieler, welche Windows-Spiele mit aktiviertem DXR-Raytracing unter Linux spielen, direkt von dieser Verbesserung:
- Weniger Shader-Overhead
- Schnellerer Traversal-Durchsatz
- Potenziell höhere Raytracing-Frameraten
Bemerkenswert ist auch, wer an dieser Erweiterung mitgewirkt hat: Unter den beteiligten Ingenieuren aus verschiedenen Organisationen findet sich auch Valves Hans-Kristian Arntzen - eine klare Indikation dafür, dass Linux-Gaming und Proton bei der Entwicklung dieser Spezifikation eine gewichtige Rolle gespielt haben. Er ist als Hauptentwickler von DXVK und VKD3D-Proton eine der zentralen Figuren des Gaming-Ökosystems von Linux. Valve macht weiterhin Jagd auf Windows.
Mehr Flexibilität für GPU-Shader
Ebenfalls neu in Vulkan 1.4.351 und mit Blick auf die Gaming-Performance interessant ist die Erweiterung VK_EXT_Shader_Split_Barrier. Qualcomm-, Intel- und Nvidia-Ingenieure haben diese Erweiterung gemeinsam entwickelt. Sie teilt den Befehl OpControlBarrier durch zwei neue Barrier-Operationen via SPIR-V auf:
- OpControlBarrierArriveEXT
- OpControlBarrierWaitEXT
Diese Funktionen erlauben es Anwendungen, den Ausführungsfluss von Subgruppen innerhalb einer Workgroup zu synchronisieren, ohne diese auf die Ankunftsbedingung warten zu lassen, bevor sie ihre unabhängige Arbeit ausführen. In der Praxis kann das die GPU-Auslastung verbessern und Wartezeiten reduzieren, was gerade in besonders compute-lastigen Spielsituationen und beim modernen Rendering ein sehr wertvoller Baustein sein kann. Auch hierbei wird ganz klar das Spielen unter Linux adressiert.
Insgesamt sechs Erweiterungewn
Das Update bringt darüber hinaus vier weitere Erweiterungen mit, die vor allem für spezifische Hardware oder Entwicklungsszenarien relevant sein können:
- VK_AMD_GPA_Interface erweitert Vulkans Werkzeugkasten um AMD-spezifische GPU-Performance-Analyse.
- Diese Vendor-Extension fügt das GPU Performance API (GPA)-Interface für den Zugriff auf globale GPU-Leistungszähler, Streaming Performance Monitors (SPM) und SQTT-Thread-Traces auf AMD-Radeon-GPUs hinzu. Für Entwickler, die Spiele auf Linux mit AMD-Hardware optimieren, ist das ein nützliches Diagnosetool.
- VK_QCOM_Elapsed_Timer_Query ist eine Qualcomm-Extension, die ähnliche Funktionalität wie die VK_ARB_Timer_Query für OpenGLs bietet und einen neuen Query-Typ einführt, um die verstrichene Zeit zwischen einer Reihe von Befehlen auszugeben.
- VK_QCOM_Image_Processing3 bringt eine neue SPIR-V Built-in-Funktion für vordefinierte Image-Gather-Operationen, die in verschiedenen Bildverarbeitungsalgorithmen wie Super-Resolution-Upscaling und Contrast-Adaptive Sharpening (CAS) eingesetzt werden.
- Upscaling-Technologien wie FSR, die unter Linux über Vulkan bereitgestellt werden, könnten langfristig von solchen erweiterten nativen Shader-Operationen profitieren.
- VK_QCOM_Shader_Multiple_Wait_QueuesAMD_GPA_Interface schließlich ist ein neuer Loop-Control-Hint für die SPIR-V-Ausführungsumgebung, der dem Compiler signalisiert, mehrere Wait-Queues zur Loop-Optimierung zu verwenden.
Auch unter der Haube wird aufgeräumt
Neben den neuen Extensions enthält Vulkan 1.4.351 laut dem offiziellen GitHub-Commit der Khronos Group auch einige interne Korrekturen: Fehlende Limits-Tabelleneinträge für VK_ARM_Tensors wurden ergänzt, eine Validierungsregel für vkCmdExecuteGeneratedCommandsEXT wurde präzisiert, und die Kompatibilität von VK_FORMAT_*_SINT-Typen mit SPIR-V-signless-Integer-Typen wurde klargestellt.
Alles in allem handelt es sich bei Vulkan 1.4.351 um ein Spezifikations-Update im XXL-Format, welches insbesondere die Spieler in den Blick nimmt und zeigt, dass sich beim Thema "Spielen unter Linux" aktuell sehr vieles in die richtige Richtung bewegt. Selbst Nvidia ist mittlerweile bei neuen Vulkan-Features ganz früh dabei.
Ihre Meinung ist gefragt!
Wie stehen Sie zu diesem Thema? Die PCGH-Redaktion freut sich über Ihre fundierte Meinung in den Kommentaren zu dieser Meldung. Um zu kommentieren, müssen Sie auf PCGH.de oder im Extreme-Forum eingeloggt sein. Sollten Sie bisher noch keinen Account haben, könnten Sie sich hier unverbindlich registrieren. Beachten Sie beim Kommentieren aber bitte die geltenden Forenregeln.
Quelle: Khronos Group via GitHub / Phoronix via VideoCardz
GlibC ist natürlich der heilige Gral, der Kern der Kompatibilität. Wenn das nicht passt, läuft glaube ich nicht mal mehr ein Container/VM. Aber ich hab noch nie gehört dass es daran scheitert. Ausnahme: Wenn dein System puristisch nur noch rein 64bit Libs verwendet. Dann ist alles, was für 32bit compiled wurde, inkompatibel
Wenn du das wirklich mal selbst erleben willst kann ich nur eine Source Distro wie Gentoo empfehlen und als Desktop versuchen ein paar Monate zu verwenden. Und dann viel Glück wenn ein GCC/Glibc Update kommt ; )
Aber darum gings eigentlich gar nicht so, es geht eigentlich darum das ein Entwickler dafür Support geben müsste. Er könnte zwar sagen "nur Ubuntu LTS" aber da würde man viele wieder nur verägern.
Zwecks der Distro Sache: Doch hat es schon. Ob ich als Entwickler offiziell ein Rolling Release, Standard Release (Ubuntu, Debian) und Enterprise OS (RHEL, Rocky LInux) supporten muss macht schon einen großen Unterschied. Man kann nicht mal die ganzen dlls dazu mitausliefern weil es oft schon an der untersten glibc ABI scheitert.
Klar arbeite ja auch nur 25 Jahre mit Linux Desktops nur ist da der Hype längst verflogen und man sieht es eben realistisch. Du kannst dich ja selbst fragen warum setzt sich Linux einfach nicht durch? Jeder wettert immer sofort "ist doch ein Unsinn" aber keiner konnte mir dazu noch eine gute Antwort geben
GlibC ist natürlich der heilige Gral, der Kern der Kompatibilität. Wenn das nicht passt, läuft glaube ich nicht mal mehr ein Container/VM. Aber ich hab noch nie gehört dass es daran scheitert. Ausnahme: Wenn dein System puristisch nur noch rein 64bit Libs verwendet. Dann ist alles, was für 32bit compiled wurde, inkompatibel
Es gibt eine Menge plausibler Antworten, und letzten Endes ist die Frage falsch gestellt, denn im Serverbereich hat sich Linux ja nicht umsonst weitestgehend durchgesetzt. Im Endgerätebereich sind die Gründe doch seit Jahren klar: der Lock-In Effekt ist enorm, dadurch dass die erwerbstätige Bevölkerung in der Breite "Windows- und Office-Skills" hat und das in Ausschreibungen wie Bewerbungen angegeben wird. Dazu kommt ein Ökosystem, das von MS gut aufgesetzt wurde und dafür sorgt, dass im Businesskontext vielen Menschen vom Status Quo profitieren. Nicht zu vergessen der bekannte Faktor "Niemand ist je dafür gefeuert worden ein System von Microsoft oder SAP einzuführen". Und halt noch die grundsätzliche Trägheit der Masse, es ist immer schwieriger vom Status Quo wegzukommen, als darauf zu beharren.
Linux APIs haben leider einen "Nachteil": Sie entwickeln sich schnell weiter und werden schnell legacy. Software, welche diese Frameworks nutzt muss nachziehen. Bei der üblichen Open Source Software kein Problem - aber closed Source wird einfach sehr schnell nicht mehr gewartet wenn es nicht mehr verkauft wird. Deswegen muss man, sehr langfristig gesehen, eigentlich immer API Wrapper bzw Kompatibilitätsschichten vorsehen.
Beispiel: SDL ist mittlerweile ein Sorgenkind bei nativen Linux builds. Ich hatte schon häufig das Problem, dass native Spiele nicht starten oder nicht korrekt unter Linux funktionieren. Es klappt dann tatsächlich besser, die Windows Version mit Proton zu wählen
Und was mir noch wichtig zu erwähnen ist, weil es ständig als Argument vorgebracht wird: Das hat alles NICHTS mit der Distribution zu tun, außer deine spezifische Distribution verweigert aus religiösen Gründen die Verwendung gewisser Libs und APIs
Zwecks der Distro Sache: Doch hat es schon. Ob ich als Entwickler offiziell ein Rolling Release, Standard Release (Ubuntu, Debian) und Enterprise OS (RHEL, Rocky LInux) supporten muss macht schon einen großen Unterschied. Man kann nicht mal die ganzen dlls dazu mitausliefern weil es oft schon an der untersten glibc ABI scheitert.