News DirectX-12 nutzt künftig SPIR-V
User-News
Von E555user
Hinweis: Diese "User-News" wurde nicht von der Planet 3DNow! Redaktion veröffentlicht, sondern vom oben genannten Leser, der persönlich für den hier veröffentlichten Inhalt haftet.In einem Beitrag des DirectX Developer Blog kündigen Cassie Hoef und Chris Bieneman vom DirectX-Entwicklerteam den Wechsel der Intermediate Representation von DXIL zu SPIR-V an.
Die Intermediate Representation dient als Zwischenschritt von einer Hochsprache wie HLSL zum spezifisch für GPUs durch den Treiber compilierten Code. Mit dieser DirectX Intermediate Language werden die Shader-Binärdateien für die DirectX-Treiber bereitgestellt. DXIL basiert auf dem LLVM-3.7 IR-Modulformat. Das heute genutzte DXIL wird mit dem geplanten Wechsel für HLSL auf Shader Model 7 ersetzt. Das DirectX-Team wird eigene Konverter für DXIL auf SPIR-V zum künftigen Shader Model 7 anbieten.
Der DXC Shader Compiler kann bereits heute SPIR-V erzeugen, muss allerdigns auf DXIL für einen DirectX-GPU Treiber übersetzt werden. Das eigene Format wird also künftig aufgegeben. In der Übersichtsgrafik der Khronos-Group bedeutet dies, dass in Zukunft der Weg von HLSL mittels DXC auch für DirectX-Treiber nur SPIR-V compiliert. OpenCLon12 und Mesa SPIR-V to DXIL können entfallen, an Stelle von DXIL tritt SPIR-V.
Die grösste Entlastung ergibt sich also für die GPU-Treiberentwickler. Es muss künftig in den Treibern je API nur noch SPIR-V unterstützt werden.
SPIR ist 2012 als OpenCL Standard Portable Intermediate Representation gestartet um die auf C basierte OpenCL-Programmiersprache auf LLVM IR abzubilden. Um die für Vulkan notwendigen Erweiterungen in einem einheitlichen Entwicklungsstrang abzubilden hat man in 2015 SPIR-V eingeführt.
SPIR-V ermöglicht es verschiedensten Hochsprachen Programme in einer standardisierten Zwischenform anzubieten, die von Vulkan-, OpenGL- oder OpenCL- und künftig DirectX-Treibern interpretiert werden kann. Eine Pflege gesonderter Compiler in den Gerätetreibern ist damit überflüssig, wodurch die Komplexität von Treibern erheblich reduziert wird. Es bleibt im zusätzlichen Support die Pflege der jeweiligen API-Aufrufe abseits des Compiler-Code für die Shader Einheiten.
Für die Entwickler bedeutet die Verwendung einer IR, dass der Kernel-Quellcode nicht offen an den Treiber übergeben wird und dass die Kernel-Ladezeiten beschleunigt werden können. Die Verwendung eines gemeinsamen Compilers für SPIR-V kommt der Zuverlässigkeit und Portabilität des Kernels über mehrere Hardware-Implementierungen hinweg zu gute.
Für Microsoft und die Khronos Group impliziert das jedoch viel mehr.
Das DirectX Team war zuletzt nach wie vor schneller in der Fortenwicklung von DirectX-Features für die Spieleprogrammierung. Ebenso hat man neben Direct3D und DXR auch mit DirectML, DirectCompute, DirectStorage und DirectSR eine ganze Reihe möglicher Applikationen, die ebenso von einer gemeinsamen IR profitieren können. Gerade die Entwicklung weg von der traditionellen Grafik-Pipeline hin zur flexiblen und leistungsfähigen Shader-Programmierung führt zu grösserem Aufwand in der Abstimmung der Schnitstellen mit den Hardware-Anbietern. So darf auch unterstellt werden, dass mit inline Raytracing, Mesh-Shading und Work-Graphs der doppelte Aufwand für die Pflege einer IR für alle Beteiligten zu gross wurde. In Zukunft wird Microsoft mit den Partnern, zuletzt vorallem AMD, die Weiterentwicklung von DirectX und Spieleprogrammierung für Kosolen auch in SPIR-V frühzeitig abbilden. Die darauf aufbauenenden und abhänigen APIs und Treiber können um so schneller einzele Entwicklungen mit unterstützen. Wo Microsoft durch Abstimmung mit der Khorons-Group Geschwindigkeit verliert, gewinnt man dort durch die schnellere Umsetzung der Hardware-Partner und auch durch Ideen und Beträge anderer. Für SPIR-V dürfen erhebliche Änderungen erwartet werden, damit die in DirectX vorangetriebenen Features unterstützt werden.
Sicherlich bleibt das GDK, Agility-SDK und die DirectX-Plattform die führende Entwicklungsumgebung für Game-Development. Durch den Schritt wird diese gefestigt hervorgehen, denn die Portierung von DirectX-Software auf andere Zielplattformen wird erleichtert.
In der aktuellen SPIR-V Übersicht fehlt allerdings Slang von Nvidia, das nur in Form von glslang vertreten ist. Dies ist eine Hochsprache für Shader-Code, um eigene experimentelle Vorstösse umsetzen zu können und ist dabei nicht nur auf Grafik sondern auch auf Compute allgemein ausgelegt. Man könnte Slang flapsig als Open Source Erweiterung von HLSL bezeichnen. Es zeigt aber, dass Microsoft selbst mit HLSL bisher zu unflexibel war neue Entwicklungen anderer selbst zu adaptieren. Hierin könnte ebenso ein Grund in der Adaption von SPIR-V liegen.
Zur Vertiefung der Schwierigkeiten rund um HLSL und der Frage nach der richtigen Hochsprache für Shader und IRs empfiehlt sich auch das Video zum Vortrag von Mateusz Kielan zur diesjährigen Vulkanized. Es besteht also die berechtigte Hoffnung dass all die von ihm vorgetragenen Probleme bald der Vergangenheit angehören, die Entwicklung könnte auch als Antwort auf seine Feststellungen verstanden werden.
Die Intermediate Representation dient als Zwischenschritt von einer Hochsprache wie HLSL zum spezifisch für GPUs durch den Treiber compilierten Code. Mit dieser DirectX Intermediate Language werden die Shader-Binärdateien für die DirectX-Treiber bereitgestellt. DXIL basiert auf dem LLVM-3.7 IR-Modulformat. Das heute genutzte DXIL wird mit dem geplanten Wechsel für HLSL auf Shader Model 7 ersetzt. Das DirectX-Team wird eigene Konverter für DXIL auf SPIR-V zum künftigen Shader Model 7 anbieten.
Der DXC Shader Compiler kann bereits heute SPIR-V erzeugen, muss allerdigns auf DXIL für einen DirectX-GPU Treiber übersetzt werden. Das eigene Format wird also künftig aufgegeben. In der Übersichtsgrafik der Khronos-Group bedeutet dies, dass in Zukunft der Weg von HLSL mittels DXC auch für DirectX-Treiber nur SPIR-V compiliert. OpenCLon12 und Mesa SPIR-V to DXIL können entfallen, an Stelle von DXIL tritt SPIR-V.
Die grösste Entlastung ergibt sich also für die GPU-Treiberentwickler. Es muss künftig in den Treibern je API nur noch SPIR-V unterstützt werden.
SPIR ist 2012 als OpenCL Standard Portable Intermediate Representation gestartet um die auf C basierte OpenCL-Programmiersprache auf LLVM IR abzubilden. Um die für Vulkan notwendigen Erweiterungen in einem einheitlichen Entwicklungsstrang abzubilden hat man in 2015 SPIR-V eingeführt.
SPIR-V ermöglicht es verschiedensten Hochsprachen Programme in einer standardisierten Zwischenform anzubieten, die von Vulkan-, OpenGL- oder OpenCL- und künftig DirectX-Treibern interpretiert werden kann. Eine Pflege gesonderter Compiler in den Gerätetreibern ist damit überflüssig, wodurch die Komplexität von Treibern erheblich reduziert wird. Es bleibt im zusätzlichen Support die Pflege der jeweiligen API-Aufrufe abseits des Compiler-Code für die Shader Einheiten.
Für die Entwickler bedeutet die Verwendung einer IR, dass der Kernel-Quellcode nicht offen an den Treiber übergeben wird und dass die Kernel-Ladezeiten beschleunigt werden können. Die Verwendung eines gemeinsamen Compilers für SPIR-V kommt der Zuverlässigkeit und Portabilität des Kernels über mehrere Hardware-Implementierungen hinweg zu gute.
Für Microsoft und die Khronos Group impliziert das jedoch viel mehr.
Das DirectX Team war zuletzt nach wie vor schneller in der Fortenwicklung von DirectX-Features für die Spieleprogrammierung. Ebenso hat man neben Direct3D und DXR auch mit DirectML, DirectCompute, DirectStorage und DirectSR eine ganze Reihe möglicher Applikationen, die ebenso von einer gemeinsamen IR profitieren können. Gerade die Entwicklung weg von der traditionellen Grafik-Pipeline hin zur flexiblen und leistungsfähigen Shader-Programmierung führt zu grösserem Aufwand in der Abstimmung der Schnitstellen mit den Hardware-Anbietern. So darf auch unterstellt werden, dass mit inline Raytracing, Mesh-Shading und Work-Graphs der doppelte Aufwand für die Pflege einer IR für alle Beteiligten zu gross wurde. In Zukunft wird Microsoft mit den Partnern, zuletzt vorallem AMD, die Weiterentwicklung von DirectX und Spieleprogrammierung für Kosolen auch in SPIR-V frühzeitig abbilden. Die darauf aufbauenenden und abhänigen APIs und Treiber können um so schneller einzele Entwicklungen mit unterstützen. Wo Microsoft durch Abstimmung mit der Khorons-Group Geschwindigkeit verliert, gewinnt man dort durch die schnellere Umsetzung der Hardware-Partner und auch durch Ideen und Beträge anderer. Für SPIR-V dürfen erhebliche Änderungen erwartet werden, damit die in DirectX vorangetriebenen Features unterstützt werden.
Sicherlich bleibt das GDK, Agility-SDK und die DirectX-Plattform die führende Entwicklungsumgebung für Game-Development. Durch den Schritt wird diese gefestigt hervorgehen, denn die Portierung von DirectX-Software auf andere Zielplattformen wird erleichtert.
In der aktuellen SPIR-V Übersicht fehlt allerdings Slang von Nvidia, das nur in Form von glslang vertreten ist. Dies ist eine Hochsprache für Shader-Code, um eigene experimentelle Vorstösse umsetzen zu können und ist dabei nicht nur auf Grafik sondern auch auf Compute allgemein ausgelegt. Man könnte Slang flapsig als Open Source Erweiterung von HLSL bezeichnen. Es zeigt aber, dass Microsoft selbst mit HLSL bisher zu unflexibel war neue Entwicklungen anderer selbst zu adaptieren. Hierin könnte ebenso ein Grund in der Adaption von SPIR-V liegen.
Zur Vertiefung der Schwierigkeiten rund um HLSL und der Frage nach der richtigen Hochsprache für Shader und IRs empfiehlt sich auch das Video zum Vortrag von Mateusz Kielan zur diesjährigen Vulkanized. Es besteht also die berechtigte Hoffnung dass all die von ihm vorgetragenen Probleme bald der Vergangenheit angehören, die Entwicklung könnte auch als Antwort auf seine Feststellungen verstanden werden.
Zuletzt bearbeitet:
