Vulkan : Der Mantle- und DirectX‑12-Konkurrent der OpenGL-Macher

, 142 Kommentare
Vulkan: Der Mantle- und DirectX‑12-Konkurrent der OpenGL-Macher
Bild: Imagination

Die Khronos Group hat im Rahmen der Game Developers Conference die neue Grafik- und Compute-API Vulkan vorgestellt, die bislang unter der Bezeichnung glNext bekannt war. Ähnlich wie DirectX 12 und AMDs Mantle soll sie Entwicklern unter anderem einen direkten Zugriff auf die GPU gewähren und den Treiber-Overhead reduzieren.

Multi-Plattform-API für alle Geräte

Ganz im Gegensatz zu Microsofts DirectX 12, das auf Windows beschränkt ist, und AMDs Mantle, das nur mit AMD-GPUs funktioniert, handelt es sich beim OpenGL-Nachfolger Vulkan aber um eine Multi-Plattform-API, die vom Smartphone über Desktops und Konsolen bis hin zu Embedded-Plattformen alle Bereiche abdecken soll, solange die Hardware die technischen Voraussetzungen für OpenGL ES 3.1 erfüllt. Eine Trennung, wie sie die Khronos Group bei OpenGL und dem für Embedded-Systeme gedachten OpenGL ES vorgenommen hat, gibt es bei der auf Basis von AMDs Mantle entwickelten Vulkan-API nicht.

Cross Platform Challenge
Cross Platform Challenge (Bild: Khronos Group)
Ground-up Explicit API Redesign
Ground-up Explicit API Redesign (Bild: Khronos Group)
Vulkan und OpenGL im Vergleich
Vulkan und OpenGL im Vergleich (Bild: Khronos Group)

Direktere Kontrolle für Entwickler

Für Entwickler ergeben sich abseits des Leistungsvorteils aus der neuen API verschiedenste Vorteile. Allen voran die direkte Kontrolle, etwa über die Speicherverwaltung und das Thread-Management, sowie ein direkter Zugriff auf die GPU durch die jeweilige Anwendung. Die Kontrolle durch die Anwendung macht diese zwar zunächst komplexer, hat aber nicht nur schlankere Treiber zur Folge, sondern verhindert auch, dass um den Treiber herum programmiert werden muss, um ein Ziel zu erreichen.

Schlankere Treiber, die sich nicht mit dem Shadersprachen-Code herumschlagen müssen, reduzieren wiederum den Overhead, erlauben mehr Draw Calls und erleichtern die Portierung auf verschiedene Plattformen. Dank einer geschichteten Architektur werden außerdem die Validierungs- und Debug-Schichten zur Maximierung der Leistung nur dann geladen, wenn sie gebraucht werden. Auch die Fehlerkorrektur, die bei OpenGL integraler Bestandteil ist, lässt sich aus Performance-Gründen bei Vulkan deaktivieren.

Zur Ausnutzung der Ressourcen moderner Rechner-Architekturen wurde Vulkan auf Multi-Threading optimiert. Beispielsweise können mehrere, von der jeweiligen Anwendung verwaltete Threads unabhängig voneinander Befehlspuffer erstellen, die dann über einen separaten Ausführungs-Thread an die GPU weitergeleitet werden.

Vulkan Multi-threading Efficiency
Vulkan Multi-threading Efficiency (Bild: Khronos Group)

SPIR-V soll mehr Flexibilität bei den Shadersprachen gewähren

Ebenso wie das neue OpenCL 2.1 nutzt nun auch Vulkan den Zwischencode SPIR-V (Standard Portable Intermediate Representation), um mehr Flexibilität bei den Shader-Sprachen zu ermöglichen und die Grafiktreiber zu vereinfachen. Möglich ist dies durch die Implementierung von Shader- und Kernel-Funktionen in der neuesten Version von SPIR-V. Durch die Teilung der Compiler-Kette können Hochsprachen-Frontends, etwa für GLSL oder HLSL, den Zwischencode in einer standardisierten Form an die Vulkan- oder OpenCL-Treiber liefern. Bei der Anpassung des Backends auf verschiedene Hardwaretechnologien kann so auf bereits vorhandene Frontends zurückgegriffen werden, da sie standardisierten Zwischencode ausgeben.

Vulkan Language Ecosystem
Vulkan Language Ecosystem (Bild: Khronos Group)

Dies hat den Vorteil, dass die Treiber selbst keinen Compiler für höhere Programmiersprachen benötigen, wodurch sie nicht nur schlanker werden, sondern auch eine potenzielle Fehlerquelle eliminiert wird. Shader können darüber hinaus schneller geladen werden und arbeiten zuverlässiger.

Als erste Shader-Sprache wird Vulkan GLSL unterstützen, für das an einem GLSL-SPIRE-V-Übersetzer gearbeitet wird. Ob die Khronos Group selbst noch weitere Frontends bereitstellen wird, ist aktuell nicht bekannt. Auf den Präsentationsfolien der GDC ist jedoch vermerkt, dass man darüber nachdenke Frontends als Open Source zu veröffentlichen.

Breite Unterstützung durch die Industrie

Die finalen Spezifikationen für Vulkan werden im Laufe des Jahres erwartet. An Unterstützung durch die Industrie wird es jedenfalls nicht mangeln, da unter anderem Branchengrößen wie AMD, Apple, ARM, Blizzard, EA, Epic, Intel, Mediatek, Nvidia, Oculur VR, Qualcomm, Samsung, Unity und Valve an der Entwicklung beteiligt sind. Für OpenGL und OpenGL ES bedeutet dies aber keines Wegs das Aus. Da sie weit verbreitet sind und für bestimmte Zwecke besser geeignet sind als Vulkan, werden sie auch weiterhin gepflegt und weiterentwickelt.

Imagination stellt erste Demo vor

Eine erste, noch sehr frühe Implementierung von Vulkan hat Imagination parallel zur Vulkan-Vorstellung als Proof of Concept demonstriert. Die Programmierer schrieben zu diesem Zweck parallel zur noch immer nicht abgeschlossenen Spezifizierung der Vulkan-Eckdaten einen Treiber für die PowerVR-Rogue-GPU und portierten eine ursprünglich für OpenGL ES 3.0 erstellte Demo auf die neue API. Bereits jetzt ist sichtbar, dass die CPU-Last mit Vulkan durchweg deutlich niedriger ist als mit OpenGL ES 3.0.

CPU-Last der Demo unter Vulkan und OpenGL ES 3.0
CPU-Last der Demo unter Vulkan und OpenGL ES 3.0 (Bild: Imagination)

Da die zur Verfügung stehende Zeit knapp bemessen war, konnten nicht alle Effekte portiert werden, viele Funktionen der ursprünglichen Demo seien aber übernommen worden. Darunter zum Beispiel HDR, 2 GiB große Texturen, die auf 266 MiB komprimiert wurden, 4×MSAA, 16×AF, mehr als 250.000 Dreiecke sowie verschiedene Post-Processing-Effekte.

Frühe Vulkan-Demo auf PowerVR-Rogue-GPUs

Update 04.03.2015 09:18 Uhr  Forum »

AMD selbst hat die Vermutung bestätigt, dass die Vulkan-API zu einem großen Teil auf Mantle aufbaut. So habe sich die Khronos Group laut AMD „die besten Teile von Mantle“ ausgesucht und diese als Basis für Vulkan genommen. Das ist es auch was AMD mit dem gestrigen Kommentar zum Ausdruck bringen wollte, dass Mantle „offener“ werde, als man bis jetzt gedacht habe.