Die GPU-APIs hatten ein Compiler-Problem, das sich hinter der Portabilität verbarg. Wenn jeder Treiber High-Level-Quellcode parsen musste, stieg die Treiberkomplexität, und jede Sprache benötigte einen Pfad in jede Laufzeitumgebung. Das machte neue Frontends schwer zu rechtfertigen.
Der Schritt von Khronos im Jahr 2015 bestand darin, die Mitte zu standardisieren. SPIR-V 1.0 definierte eine kompakte binäre Zwischensprache für grafische Shader und Compute-Kernel. OpenCL 2.1 garantierte deren Verarbeitung, und Vulkan übernahm sie als Shader-Eingabe.
Das Clevere war die Aufteilung: Frontends erzeugen SPIR-V, Treiber konsumieren SPIR-V. Khronos erklärte, dies verringere die Komplexität des eingebauten High-Level-Compilers, fördere die Sprachenvielfalt, verbessere die Portabilität und ermögliche es, Teile der Kompilierung und Reflexion offline durchzuführen.
Den Treiber IR statt Quellcode konsumieren lassen
Die binäre IR wurde vollständig von Khronos spezifiziert, sodass Anbieter Backends optimieren konnten, ohne die Quellsprache zu besitzen.
Die Verwendung derselben IR in Vulkan und OpenCL gab Tool-Entwicklern ein einziges Ziel für Grafik und Compute.
Offline-Kompilierung reduzierte die Shader-Arbeit zur Laufzeit und erleichterte Validierung, Reflexion und Tooling.
Open-Source-Übersetzer, Assembler und Disassembler halfen, das Ökosystem zum Start zu begründen.
Eine standardisierte Zwischenform kann ein N-mal-M-Compiler-Problem in zwei kleinere Märkte verwandeln: viele Frontends und viele optimierte Backends.
SPIR-V wurde ein Kernbestandteil der Vulkan- und OpenCL-Toolchains. Seine vereinheitlichte Spezifikation deckt nun alle Versionen seit 1.0 ab, und Khronos pflegt es weiterhin als portable binäre Schicht unter mehreren Grafik- und Compute-APIs.
DEN BELEGEN FOLGEN
Die Quellen
- Khronos Releases OpenCL 2.1 and SPIR-V 1.0 Specifications for Heterogeneous Parallel Programming Khronos Group · khronos.org ·
- SPIR-V Specification Khronos Group · registry.khronos.org