Khronos neues Grafik-API Vulkan erblickt das Licht der Welt

Happy Birthday, Vulkan – Dif-tor heh smusma!
Kommentare

Wir schreiben den 16. Februar 2016. Ein neues und vielversprechendes Grafik-API erblickt das Licht der Welt. „Happy Birthday, Vulkan!“, oder um es mit den Worten unseres Lieblingsvulkaniers Mr. Spock auszudrücken: „Live long and prosper (Dif-tor heh smusma)!“

Für einen Grafikprogrammierer ist die Veröffentlichung des Vulkan-API natürlich zuallererst ein Tag der Freude. Die Bedeutung dieses Tages wird letzten Endes aber davon abhängig sein, ob Vulkan sich zukünftig als ernstzunehmende DirectX-Alternative zu etablieren vermag.

So kann ich mich beispielsweise noch sehr gut an den 19. Dezember 2002 erinnern: DirectX 9 trat seinen Siegeszug an und leitete das Zeitalter der Shader-Programmierung ein. Dank HLSL, der High Level Shader Language, wurde die Implementierung von Shader-Programmen zum Kinderspiel. Von nun an konnten Grafikprogrammierer ihre eigenen Transformations- und Beleuchtungsroutinen schreiben, neue Beleuchtungstechniken entwickeln und ihre Spielewelten mit einem individuellen Look versehen. DirectX lief zwar nur auf Windows-Rechnern, doch damit konnte man leben, denn Linux führte ein Nischendasein und Smartphones sowie Tablets waren noch Zukunftsmusik.

Als im Jahr 2007 jedoch Windows Vista veröffentlicht wurde, begannen die Dinge mit einem Mal kompliziert zu werden. Zusammen mit dem neuen Betriebssystem wurde das neue DirectX-10-API eingeführt. Benutzer von Windows XP hatten leider das Nachsehen und mussten sich weiterhin mit dem bereits in die Jahre gekommenen DirectX 9 arrangieren.

Und die Spieleentwickler? Die mussten sich plötzlich mit zwei API-Versionen herumschlagen: Einerseits würden Spiele ohne DirectX-10-Unterstützung bald schon zum alten Eisen gehören, andererseits konnte man DirectX 9 aber nicht einfach so in Rente schicken, da sich Windows XP nach wie vor großer Beliebtheit erfreute, während sich Windows Vista als Rohrkrepierer entpuppte. Hätte es zu diesem Zeitpunkt bereits ein mit DirectX 10 vergleichbares, plattformunabhängiges Grafik-API gegeben, wer weiß, was dann geschehen wäre …?

Einfluss von OpenGL

Leider gab es da nur das technisch veraltete OpenGL 2.x, das jedoch aus nachvollziehbaren Gründen von den allermeisten Spieleentwicklern schlicht und einfach ignoriert wurde. Bis zur Veröffentlichung der OpenGL-Spezifikationen 3.3 (als Alternative zu DirectX 10) und 4.x (als Alternative zu DirectX 11) im Jahr 2010 sollte sich an der Vormachtstellung von DirectX nicht viel verändern. Und auch dann wäre der Einfluss von OpenGL (ES) auf die Spieleentwicklung wohl nach wie vor überschaubar geblieben, wäre es nicht zur gleichen Zeit zu dem bis heute andauernden Tablet- und Smartphoneboom gekommen.

User wollen Spiele für Tablets und Smartphones.

Viele Menschen wollten mittlerweile nicht mehr länger nur am heimischen PC oder der Konsole spielen. Sie wollten Spiele für unterwegs, Spiele für ihre mobilen Endgeräte (Mobile Games), Spiele für ihre Tablets und Smartphones. Und weil sich diese Spiele nun einmal nicht mithilfe von DirectX entwickeln ließen, wurde schließlich OpenGL ES zum Standard-Grafik-API im Bereich der Mobile-Games-Entwicklung. Anfangs dominierten einfache, aber nichtsdestotrotz unterhaltsame 2-D-Spiele den Markt, da die Grafikleistung mobiler Geräte damals noch recht bescheiden war. Heutzutage lassen sich hingegen auch in zunehmendem Maße dreidimensionale Spielewelten auf einem Tablet-Computer bestaunen.

Stellen Sie Ihre Fragen zu diesen oder anderen Themen unseren entwickler.de-Lesern oder beantworten Sie Fragen der anderen Leser.

Vulkan – ein ungerechtfertigter Hype?

Ziehen wir ein Zwischenfazit: Wer 3-D-Spiele sowohl für den PC als auch für leistungsfähige mobile Endgeräte entwickeln will, der sollte auf OpenGL (ES) setzen. Wenn die grafische Qualität der betreffenden Spiele zufriedenstellend ist und die erzielten Frame-Raten überdies ein ruckelfreies Spielvergnügen ermöglichen, gibt es eigentlich keinen Grund, nach einem anderen Grafik-API Ausschau zu halten. Ist der ganze Hype rund um die neue Vulkan-Schnittstelle also letzten Endes doch nicht gerechtfertigt?

Es steht außer Frage, dass man mithilfe von OpenGL performante 3-D-Anwendungen entwickeln kann, sofern man sich an eine einfache Regel hält: Sowohl der Datenaustausch als auch die Kommunikation zwischen CPU und GPU sollten auf ein Minimum beschränkt bleiben. Auf die Möglichkeiten, wie sich dieses Ziel erreichen lässt, sind wir bereits ausführlich in unseren OpenGL-Artikeln zu sprechen gekommen:

  • Die Anzahl der Rendering-Aufrufe (Draw Calls) lässt sich mithilfe von Geometry Instancing verringern.
  • Texturwechsel lassen sich durch Verwendung von Texture-Array-Objekten auf ein Minimum reduzieren.
  • Umfangreiche Datensätze sollten mithilfe von Texture-Buffer-Objekten, kleinere Datensätze mithilfe von Uniform-Buffer-Objekten verwaltet werden.

Wenn die GPU aufgrund umfangreicher Berechnungen an ihr Limit stößt, dann kann ein neues Grafik-API selbstverständlich keine Wunder bewirken. Ist hingegen das Zusammenspiel von CPU und GPU für die Performanceprobleme verantwortlich, dann sieht die Sache gleich ganz anders aus. Um die Gründe hierfür verstehen zu können, muss man sich vergegenwärtigen, dass die erste OpenGL-Spezifikation aus einer Zeit stammt (1992), in der Single-Core-CPUs den Markt dominierten.

Rendering-spezifische Aufgaben lassen sich mit Vulkan auf mehrere CPU-Kerne aufteilen.

Technisch gesehen ist OpenGL eine globale Zustandsmaschine (Global State Machine), bei der sämtliche anstehende Aufgaben nacheinander (sequenziell) in einem einzelnen Thread abgearbeitet werden (Single-Threaded Rendering). Globale Zustände gehören dank Vulkan jedoch endgültig der Vergangenheit an, und Rendering-spezifische Aufgaben lassen sich, falls erforderlich, auf mehrere CPU-Kerne aufteilen (Multi-Threaded Rendering). Zusätzlich dazu ist bei einer großen Anzahl von Draw Calls die Performance einer Vulkan-Anwendung aufgrund des deutlich reduzierten Treiberoverheads weitaus besser als bei einem vergleichbaren OpenGL-Programm.

Allerdings sind wir als Programmierer im Gegenzug nun aber auch für das GPU-Speicher- und Ressourcenmanagement sowie für mögliche Fehlerüberprüfungen verantwortlich. Im Unterschied zu einem OpenGL-Treiber ist ein Vulkan-Treiber nicht mehr für die Kompilierung der Shader-Programme zuständig. Hierdurch entfällt nicht nur die Notwendigkeit, dass man den GLSL-Programmcode mitsamt der Grafikanwendung veröffentlichen muss. Zusätzlich dazu werden aufwendige Shader-Berechnungen in Zukunft auch weitaus seltener zu unvorhersehbaren Ergebnissen führen.

Erfahrungen mit OpenGL und auf der Suche nach einem neuen Job? Entwicklerjobs hilft!

Vielleicht kennen Sie ja das Problem, dass komplexe Shader, die bislang einwandfrei funktionierten, nach einem Grafiktreiber-Update plötzlich Probleme verursachen. Unter Vulkan werden sämtliche Shader bereits im Verlauf der Programmentwicklung kompiliert und in Form von SPIR-V-Binärcode (Standard Portable Intermediate Representation) gespeichert, der sich dann später zur Laufzeit der betreffenden Grafikanwendung direkt an die GPU übermitteln lässt.

Die Zukunft von Vulkan

Spekulationen über die Zukunft des Vulkan-API sind zum jetzigen Zeitpunkt eindeutig verfrüht, zumal augenblicklich bei Weitem noch nicht alle Plattformen unterstützt werden. Beginnen wir damit, dass Apple mit „Metal“ ein eigenständiges hardwarenahes Grafik-API entwickelt hat. Auf der Playstation 4 wäre der Einsatz von Vulkan zwar denkbar, die Performance von Sonys eigenem Low-Level-API GNM dürfte jedoch bei Weitem nicht erreicht werden. Für die Xbox One ist eine Unterstützung des Vulkan-API ebenfalls wenig wahrscheinlich, da Vulkan in direkter Konkurrenz zu DirectX 12 steht.

Aber wir sollten an dieser Stelle vielleicht damit aufhören, alles immer nur negativ zu sehen, denn wie heißt es doch gleich: Was die Zukunft bringt, wird sich erst in der Zukunft zeigen. Hoffen wir also, dass dem neuen Vulkan-API noch ein langes und erfolgreiches Leben bevorsteht.

Aufmacherbild: Tungurahua Volcano Exploding In The Night Of 28 11 2011 Ecuador von Shutterstock / Urheberrecht: Ammit Jack

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -