Am 26. Juni 2026 tauchte im Zig-Entwicklerlog ein Eintrag auf: »SPIR-V Backend Progress«. Autor ist Ali Cheraghi, der Kernbeitragende des SPIR-V-Backends im Zig-Compiler. Es handelt sich nicht um einen Meilenstein-Beitrag à la »Das SPIR-V-Backend ist jetzt produktionsreif« – im Gegenteil, große Abschnitte räumen Bitrot, Single-Thread-Einschränkungen und lediglich 49 % bestandene Verhaltenstests ein. Dennoch wurde dieser Eintrag noch am selben Tag mit 28 Punkten auf die Lobsters-Startseite gehoben; alle drei Kommentare drückten Begeisterung aus.
Ich versuche, die Quelle dieser Begeisterung zu verstehen. Ein selbstgehostetes Compiler-Backend mit weniger als der Hälfte bestandener Verhaltenstests, das nach der Zusammenführung in den Hauptzweig an mehreren Stellen zerbrach und wochenlange Reparaturen erforderte – nach jedem traditionellen Maßstab der Softwarebereitstellung wäre das als »frühes Experiment« einzustufen. Die Community aber las ein völlig anderes Signal heraus: Eine Systemprogrammiersprache beginnt, einen Brückenkopf im GPU-Bereich zu errichten.
Wo SPIR-V im GPU-Ökosystem steht
Um dieses Signal zu verstehen, muss man zunächst die Position von SPIR-V im GPU-Ökosystem begreifen.
SPIR-V ist eine von der Khronos Group definierte binäre Zwischenrepräsentation (IR), die Vulkan, OpenCL, OpenGL bedient und in naher Zukunft auch von DirectX konsumiert wird. Ihr zentrales Designziel ist einfach: Die Kompilierung von Shader-/Compute-Kernels aus dem Treiber herauszunehmen und auf die Anwendungsseite zu verlagern. Vor SPIR-V bestand der Standardpfad der GPU-Programmierung darin, Quelltext in GLSL oder HLSL zu schreiben und dem Treiber zur Laufzeitkompilierung zu übergeben. Die Compiler in den Treibern waren von uneinheitlicher Qualität; Kompilierungsergebnisse konnten zwischen Herstellern und Treiberversionen variieren. SPIR-V änderte diese Arbeitsteilung: Das Sprach-Frontend ist für die Erzeugung konformer SPIR-V-Binaries verantwortlich, der Treiber nur noch für die Übersetzung in die GPU-ISA. Die Compiler-Verantwortung wanderte vom Treiber zur Sprach-Toolchain.
Dieser Schritt bedeutet: Jedes Compiler-Frontend, das konformes SPIR-V erzeugen kann, wird zum Einstiegstor für GPU-Programmierung. Kein GLSL mehr nötig. Kein HLSL mehr nötig. Der Vulkan-Standard selbst interessiert sich nicht dafür, ob dein SPIR-V-Binary aus GLSL übersetzt oder direkt aus C++, Rust, Julia – oder Zig – kompiliert wurde.
Deshalb ist ein Compiler-Backend, das SPIR-V ausgeben kann, so bedeutsam. Der Compiler einer universellen Programmiersprache kann direkt GPU-Code erzeugen – die Grenze zwischen Shader-Sprache und Universalsprache beginnt zu verschwimmen.
Was Zigs Backend bisher erreicht hat
Der Entwicklerlog vom 26. Juni 2026 deckt fünf Fortschrittsdimensionen ab. Ich ordne sie nach ingenieurtechnischer Bedeutung:
Erstens: Die Builtin-Anweisung @SpirvType. SPIR-V kennt Typen ohne direktes Gegenstück in Zigs Typsystem – Sampler, Image, Sampled Image, Runtime Arrays. Bisher konnten diese Typen nur über Inline-Assembly mit handgeschriebenen SPIR-V-Instruktionen ausgedrückt werden – was jahrelang als »das größte Hindernis beim Shader-Schreiben« galt. @SpirvType erhebt GPU-spezifische Typen zu einem vom Compiler erkannten First-Class-Konzept; man kann im Code mit Zig-Syntax einen Sampler deklarieren und an ein Descriptor-Set und eine Binding-Stelle binden. Dies ist der entscheidende Sprung von »kann SPIR-V-Instruktionen erzeugen« zu »kann in Zig auf natürliche Weise Shader schreiben«.
Zweitens: Ausführungsmodi werden über Calling Conventions getragen. Workgroup-Größe, Fragment-Ursprung, Mesh-Shader-Parameter – diese Informationen wurden bisher manuell über Inline-Assembly OpExecutionMode eingefügt. Im neuen Design deklariert man eine Funktion mit der Calling Convention callconv(.{ .spirv_kernel = .{ .x = 8, .y = 8, .z = 1 } }), und der Compiler leitet den korrekten Ausführungsmodus automatisch ab. Gleichzeitig wurden die beiden neuen Calling Conventions spirv_task und spirv_mesh für Mesh-Shading-Pipelines hinzugefügt. Von der Nutzerseite aus betrachtet wird die Deklaration der Einstiegsfunktion eines Compute-Shaders so natürlich wie die einer normal exportierten Zig-Funktion.
Drittens: Multithread-Codegenerierung. Das SPIR-V-Backend lief von Anfang an single-threaded innerhalb des Linker-Threads. Dieses Refactoring integriert es in die einheitliche MIR-zu-Codegenerierung-Pipeline des Compilers; jede Codegenerierungsaufgabe wird wie bei den anderen selbstgehosteten Backends im Thread-Pool verteilt. Gleichzeitig kehrten die beiden ISel-Passes dedup_types (Zusammenführung doppelter Typinstruktionen) und prune_unused (Entfernung toten Codes) zurück – beide waren im vorherigen Single-Thread-Refactoring gelöscht worden und konnten dank des Architektur-Upgrades wiederhergestellt werden. Für Nutzer bedeutet das höhere Kompilierungsgeschwindigkeit; ingenieurtechnisch bedeutet es, dass das SPIR-V-Backend seinen »Sonderbehandlungs«-Status verlassen hat und eine gleichberechtigte Kompilierungseinheit neben anderen Targets geworden ist.
Viertens: Objektdatei-Verknüpfung. .spv-Dateien werden jetzt als Objektdateiformat erkannt. Mehrere .zig-Dateien (oder externe .spv-Objekte) können kompiliert und vom SPIR-V-Linker zu einem einzigen Modul zusammengeführt werden. Das bedeutet, dass große Shader-Projekte in mehrere Kompilierungseinheiten aufgeteilt werden können – theoretisch mit inkrementeller Kompilierung und Bibliotheksverteilung, auch wenn diese fortgeschrittenen Workflows noch nicht einsatzbereit sind. Das Fundament auf Formatebene ist jedoch gelegt.
Fünftens: Capabilities und Extensions werden vom CPU-Feature-Set getrieben. Früher wurden OpCapability und OpExtension ad hoc von der Codegenerierung oder Inline-Assembly eingefügt; jetzt werden Abhängigkeitsketten aus den SPIRV-Headers extrahiert und einheitlich vom CPU-Feature-Set verwaltet. Der Assembler verweigert jeden manuellen Einfügeversuch dieser Instruktionen – der Compiler beginnt, systemische Verantwortung für die Korrektheit seiner Ausgabe zu übernehmen, statt die Validierung dem nachgelagerten spirv-val-Tool zu überlassen.
Im Vergleich zu vor vier Wochen stieg die Verhaltenstest-Quote von etwa 39 % auf 49 % (Target spirv64-vulkan), dutzende Bugs wurden behoben, std.gpu wurde in std.spirv umbenannt. Cheraghis eigene Formulierung ist zurückhaltend: »Das SPIR-V-Backend ist sinnvoll brauchbarer als vor einem Monat, aber noch weit vom Ziel entfernt.«
Im Vergleich mit der Konkurrenz
Zig ist nicht das einzige Projekt, das versucht, von einer Universalsprache aus die GPU zu erschließen. Ein vergleichender Blick auf die wichtigsten Konkurrenten hilft, die Position des Zig SPIR-V-Backends präziser zu bestimmen.
Rust GPU (rust-gpu) ist der direkteste Referenzpunkt. Basierend auf rustc_codegen_spirv kompiliert es Rust zu SPIR-V-Shadern. Das Projekt begann etwa 2019, erfuhr Unterstützung durch Embark Studios und wurde später an die Community übergeben. Es bietet derzeit eine grundlegend nutzbare Standardbibliothek-Teilmenge (spirv-std), eine browserfähige SHADERed-Demo und ein experimentelles SPIR-T-Framework für Link-Time-Optimierung. Aus GitHub-Issues und Community-Diskussionen geht jedoch hervor, dass Rust-Compiler-Upgrades häufig Anpassungen des Codegen-Plugins erfordern; eine stabile Version steht noch aus.
Circle C++ Shader Compiler erlaubt es, Shader in Standard-C++ zu schreiben; Attribut-Markierungen grenzen GPU-Einstiegspunkte ab, das Kompilat ist direkt SPIR-V. Syntaktisch ähnelt es CUDA – eine einzelne Quellsprache, C++-Superset. Circle ist jedoch ein Closed-Source-Compiler, abhängig von Sean Baxters Einzelwartung, mit begrenzter ökologischer Reichweite.
Julia GPU bietet GPU-Programmierung über CUDA.jl und AMDGPU.jl, umgeht SPIR-V auf unterer Ebene und erzeugt direkt PTX- oder AMDGCN-Instruktionen. Der Vorteil liegt in der interaktiven Entwicklung – Kernels können im REPL ad hoc geschrieben und ausgeführt werden. Der Nachteil ist ebenso deutlich: Herstellerübergreifende Portabilität hängt vom Paketökosystem ab, nicht von einem Standard-IR.
Die Position des Zig SPIR-V-Backends auf dieser Karte ist spezifisch: Es ist die einzige Systemprogrammiersprache, deren SPIR-V-Backend ein selbstgehostetes Compiler-Backend ist – rust-gpu ist ein externes Codegen-Plugin des Rust-Compilers, kein First-Class-Bestandteil des Rust-Projekts; Circle ist ein Closed-Source-Einzelprojekt; Julia umgeht SPIR-V. Zigs SPIR-V-Backend wird im selben Repository, mit demselben Build-System und von denselben Kernbeitragenden gewartet wie die x86-, ARM- und RISC-V-Backends.
Das ist ein zweischneidiges Schwert. Im selben Repository wie die Compiler-Hauptlinie zu liegen bedeutet, dass das SPIR-V-Backend bei jeder Architekturanpassung des Zig-Compilers passiv mitentwickelt wird – Bitrot ist der Preis dieser engen Kopplung. Es bedeutet aber auch, dass jede Verbesserung der Compiler-Infrastruktur (Typsystem, Codegenerierungspipeline, Linker) dem SPIR-V-Backend automatisch zugutekommen kann. Die Wiederherstellung der Multithread-Codegenerierung im Log vom 26. Juni ist ein konkretes Beispiel dieses Mechanismus: Die Architekturentscheidung für eine vereinheitlichte MIR-Pipeline bescherte dem SPIR-V-Backend »kostenlos« die Thread-Pool-Scheduling-Fähigkeit.
Die wahren Hindernisse liegen nicht im Compiler
Aus technischer Roadmap-Perspektive liegen die größten Hindernisse für das Zig SPIR-V-Backend nicht vollständig innerhalb des Compilers.
Das erste Hindernis ist der Adressraum. Das GPU-Speichermodell unterscheidet Global, Local, Private, Constant und weitere Adressräume, während Zigs Pointer standardmäßig den generischen Adressraum annimmt. Cheraghis Blog erwähnt, dass Vulkan OpPtrCastToGeneric nicht unterstützt – daher nimmt die aktuelle Implementierung als Übergangslösung an, dass alle Pointer der Function Storage Class angehören. Das bedeutet, dass komplexe Pointer-Operationen (z. B. Referenzen über Adressräume hinweg) unter dem Vulkan-Target eingeschränkt sind. Unter dem OpenCL-Target ist die Situation etwas besser, da die OpenCL-Baseline mehr Fähigkeiten garantiert; auch die Verhaltenstest-Quote ist höher (etwa 75 %).
Das zweite Hindernis sind Unterschiede in der numerischen Semantik. Instruktionen wie fma, sqrt, exp, log garantieren in der Vulkan-Umgebung keine korrekte Rundung – dies steht im Konflikt mit den Standardannahmen des Zig-Compilers zur numerischen Semantik. Zigs Anspruch an Determinismus liegt über der typischen Toleranz von Shader-Sprachen gegenüber numerischer Genauigkeit. Dies ist nicht unbedingt ein unlösbares Problem – Rust GPU und GLSL-Compiler standen vor derselben semantischen Kluft –, aber es erfordert explizite Designentscheidungen und Dokumentation, beides derzeit noch in Arbeit.
Das dritte Hindernis liegt auf Ökosystemebene: die Anpassung der Standardbibliothek. Auf der GPU gibt es kein Betriebssystem, kein Dateisystem, keinen Heap-Allokator (zumindest nicht im herkömmlichen Sinn). Zigs Standardbibliothek enthält umfangreichen Code, der auf diesen Annahmen aufbaut. std.math, std.sort sowie die gängigen Datenstrukturen und Algorithmen auf eine GPU-freundliche Teilmenge zu portieren, ist ein Unterfangen von nicht geringerem Umfang als das Compiler-Backend selbst. Cheraghi listet in seiner »Next Steps«-Aufstellung Prefix Sum, Reduction, Matrixmultiplikation und andere grundlegende Algorithmen auf – die Bausteine für HPC- und ML-Workloads. Die Priorisierung ist richtig, zeigt aber auch, dass der Fortschritt noch in einer frühen Phase steckt.
Warum dieser Log-Eintrag Aufmerksamkeit erregte
Zurück zu dem Lobsters-Post mit 28 Punkten. Die Begeisterung jenseits technischer Details speist sich aus zwei Quellen.
Die eine Quelle ist ein zeitlicher Marker. Am selben Tag erschien im Zig-Entwicklerlog ein weiterer Eintrag – Matthew Luggs »New @bitCast Semantics and LLVM Backend Improvements« – der auf Lobsters separat 16 Kommentare erhielt. Zwei Zig-Compiler-Fortschritte an einem Tag auf der Lobsters-Startseite sind in dieser Community kein Normalzustand. Es signalisiert die Vitalität des Sprachökosystems: Der Zig-Compiler treibt gleichzeitig mehrere Dimensionen voran – Integer-Degradierung, bitCast-Semantik, LLVM-Backend-Optimierung, SPIR-V-Backend-Reparatur. Das ist kein Projekt, das nur auf einem einzigen Pfad iteriert.
Die andere Quelle ist ein Richtungssignal. Allein die Existenz des SPIR-V-Backends sagt: Zigs Maintainer sind der Ansicht, dass eine Systemprogrammiersprache GPU-Code kompilieren können sollte. Das ist die Erklärung, dass die GPU legitimes Territorium der Systemprogrammierung ist – eine Quote von 49 % erlaubt noch kein »Wir unterstützen jetzt auch GPUs«, aber die Ansage ist unmissverständlich.
Diese Richtung unterscheidet sich von Rusts GPU-Geschichte. Rusts Sicherheitsphilosophie hat auf der GPU einen klaren differenzierenden Wert – das Ownership-System kann Datenwettläufe zur Kompilierzeit verhindern, was im hochparallelen GPU-Programmiermodell ein natürlicher Vorteil ist. Zigs Wertversprechen ist anders: keine impliziten Allokationen, Compile-Time-Berechnung in derselben Sprache, explizite Kontrolle über den Kontrollfluss. Auf der GPU bedeutet »keine impliziten Allokationen«, dass man nicht aus Versehen einen Aufruf an einen nicht existierenden Heap-Allokator auslöst. Comptime bedeutet, dass Workgroup-Verteilungsstrategien, Speicherlayouts und Unroll-Faktoren zur Kompilierzeit basierend auf dem GPU-Feature-Set dynamisch entschieden werden können – ohne Makros, ohne Codegenerierungsskripte.
Welcher Ansatz besser für GPU-Programmierung geeignet ist? Ich habe keine Grundlage für ein Urteil. Beide Sprachen befinden sich in ihren GPU-Versuchen noch in einem zu frühen Stadium; die Datenarmut erlaubt keine vergleichenden Schlussfolgerungen. Aber aus Sicht der ökologischen Vielfalt ist es besser, wenn zwei Systemsprachen mit unterschiedlichen Philosophien gleichzeitig SPIR-V angreifen, als wenn es nur eine gäbe.
Bescheidenheitserklärung
Die Analyse dieses Textes beruht auf dem Zig-Entwicklerlog vom 26. Juni 2026, Ali Cheraghis Blogartikel »Zig and GPUs«, der Lobsters-Community-Diskussion sowie den öffentlichen Dokumenten der Khronos SPIR-V-Spezifikation. Ich habe nicht zum Zig-Compiler beigetragen und selbst keine Shader unter dem Target spirv64-vulkan gebaut oder ausgeführt. Die zitierte Quote von 49 % bestandener Verhaltenstests stammt aus der Selbstauskunft des Entwicklerlog-Autors und wurde nicht unabhängig verifiziert. Die Beschreibungen des aktuellen Stands von Rust GPU, Circle und Julia GPU basieren auf öffentlichen Repositories, Community-Diskussionen und wissenschaftlichen Veröffentlichungen – die tatsächliche Nutzbarkeit der einzelnen Projekte kann je nach Einsatzkontext erheblich abweichen. Wer in einem der genannten Bereiche direkte Ingenieurserfahrung hat, ist eingeladen, auf die Grenzen dieses Textes hinzuweisen.