Ein erster Blick auf die Grafik-API Vulkan
Vulkan ist noch immer in Entwicklung und als Nachfolger von OpenGL für viele Entwickler bisher ein Mysterium. Bei der Siggraph 2015 stellte Imagination Technologies nun eine Demo für den Prototypen des kommenden Standards der Khronos-Gruppe vor.
- Julia Schmidt
Vulkan ist noch immer in Entwicklung und als Nachfolger von OpenGL für viele Entwickler bisher ein Mysterium. Bei der Siggraph 2015 stellte Imagination Technologies nun eine Demo für den Prototypen des kommenden Standards der Khronos-Gruppe vor.
Software Design Engineer Tobias Hector beantwortet einige Fragen zum Projekt.
heise Developer: Herr Hector, Imagination Technologies hat einen guten Einblick in die Entwicklung der Vulkan-API. Welche Sprache steht bei der Umsetzung im Vordergrund?
T. Hector: Vulkan ist eine C-API. Im Moment gibt es keine Pläne für Bindungen an andere Sprachen. Allerdings gehen wir davon aus, dass Open-Source-Entwickler mit der Zeit entsprechende Möglichkeiten zum Einsatz von C++ und anderen Sprachen anbieten werden.
heise Developer: OpenGL war ein plattform- und sprachagnostischer Standard. Wie passt da diese Bindung an C ins Bild?
T. Hector: Wie bei den meisten anderen Khronos-APIs erfolgt auch bei Vulkan die offizielle Implementierung in C – das gilt auch für die Konformitätstests.
Die Vulkan-API
Die von der Khronos Group entwickelte Programmierschnittstelle OpenGL abstrahiert vergleichsweise stark von der Hardware. Nachdem Microsoft seinen Entwicklern mit einer neuen Version von DirectX hardwarenäheres Programmieren ermöglicht, bewegt sich auch Khronos mit Vulkan in diese Richtung. Die API wurde auf der SIGGRAPH 2014 als glNext vorgestellt, ihre Erstauslieferung ist gegen Ende 2015 geplant. Demos mit ersten Prototypen legen bereits nahe, dass Vulkan die GPU besser nutzen können wird und den CPU-Gebrauch verringert.
C findet deshalb Verwendung, weil die Sprache eine Art "Lingua franca" darstellt, die von den meisten Programmier- beziehungsweise Skriptsprachen ansprechbar ist. Die Spezifikation selbst sollte sich in jeder Programmiersprache implementieren lassen, die Funktionen unterstützt – selbst, wenn die offiziellen Dokumente in C vorliegen.
Abstraktionsgrad und Zwischenformat
heise Developer: Sowohl DirectX als auch OpenGL sind vergleichsweise hardwarenah konzipiert, sodass dem Nutzer wenige Komfortfunktionen zur Verfügung stehen. Ist bei Vulkan mit einem ähnlichen Abstraktionslevel zu rechnen?
T. Hector: DirectX und OpenGL/OpenGL ES sind High-Level-Interfaces, die den Zugriff auf ein von der GPU realisiertes Abbild einer Rendering-Pipeline ermöglichen. Im Vergleich zu OpenGL ist Vulkan eine wesentlich schlankere Abstraktionsschicht, die Entwicklern das Realisieren eigener Pipelines und damit einhergehend eine bessere Auslastung von CPU und GPU ermöglicht.
Wie bei allen neuen APIs gehen wir auch hier von einer gewissen Lernkurve aus. Unserer Meinung nach wird Vulkan in der Anfangszeit vor allem in Gebieten ausprobiert werden, in denen Experten besonderen Wert auf die Performance legen. Engine-Entwickler und Programmierer von hoch budgetierten Spielen (AAA-Titel) werden sich folglich wohl als Erste mit der Schnittstelle befassen.
heise Developer: Häufig trifft man auf die Meinung, dass die OpenGL-Architektur besonders beim Kompilieren der Shader nur zu höherer Performance führte, weil die involvierten Anbieter ihr Wissen über die eigene Hardware in den Optimierungsprozess einbringen. Kann es sein, dass der Einsatz von SPIR (Standard Portable Intermediate Representation) als Zwischenformat zur Folge hat, dass die Entwicklung der Treiber leidet, da man sie eventuell weniger gründlich implementiert?
T. Hector: SPIR-V ist immer in den Befehlssatz der GPU zu übersetzen. In vielen Fällen gehen die Anbieter sogar soweit, noch eine hauseigene Intermediärsprache zwischenzuschalten. Unserer Meinung nach ist es wahrscheinlich, dass sich das Compiler-Backend moderner Shader-Kompilierungs-Toolchains mit SPIR-V und existierenden Sprachen teilen lässt.
Zudem sorgen die mit Vulkan neu eingeführten Pipeline State Objects dafür, dass dem Compiler ergänzende Kontext- und Metainformationen zur Verfügung stehen. Das zusätzliche Wissen über die Arbeitsumgebung dürfte zu einer zusätzlichen Effizienzsteigerung führen.
heise Developer: Google begann vor einiger Zeit damit, eine eigene Shader-Programmierumgebung auszuliefern und hat OpenCL sogar auf Geräten blockiert. Denken Sie, dass Google auf Vulkan ähnlich reagieren wird?
T. Hector: Google hat sich der zunehmend größer werdenden Menge von Firmen angeschlossen, die Vulkan unterstützen. Auf der SIGGRAPH 2015 kündigte das Unternehmen an, dass die Schnittstelle in einer zukünftigen Version von Android nutzbar sein wird. Zudem möchte Google eine umfangreiche und quelloffene Testsuite zur Verfügung stellen, die auf allen Vulkan-Plattformen lauffähig sein soll.
Wichtig ist, dass Android OpenGL ES weiter unterstützen wird. Entwickler haben hier also die Freiheit, auf die API zu setzen, die ihnen sinnvoller erscheint.
