: Alexander Rudolph
: Das Vulkan-API Teil 2: Wie man ein Framework erstellt und Shader programmiert
: entwickler.press
: 9783868027662
: 1
: CHF 2.70
:
: Hardware
: German
: 56
: Wasserzeichen
: PC/MAC/eReader/Tablet
: ePUB
Bevor das neue plattformunabhängige Grafik-API Vulkan seinen explosiven Namen erhielt, wurde es in Fachkreisen schlicht als 'OpenGL Next' bezeichnet. Und die Verwandtschaft zwischen den beiden APIs ist nicht abzustreiten, zumal beide die gleiche Sprache für die Shader-Programmierung verwenden: die OpenGL Shading Language (GLSL). Trotzdem werden Grafikprogrammierer schnell feststellen, dass Vulkan nicht nur deutlich mehr Möglichkeiten und Performance bietet als sein Vorgänger, sondern auch ungleich komplizierter in der Handhabung ist. In seinem zweiten Vulkan-shortcut geht Alexander Rudolph auf genau diese Schwierigkeit ein, indem er den Leser über die Erstellung eines einfaches Frameworks in die wichtigsten Funktionen des Low-Level-APIs einführt. Im zweiten Schritt gibt er dann einen Überblick über verschiedene Shader-Typen und einen Einstieg in die GLSL-Programmierung für Vulkan.

Alexander Rudolph schrieb zwei Bücher über das Thema Spieleprogrammierung mit DirectX für den Markt+Technik Verlag, eine Artikelserie über die Spieleentwicklung mit OpenGL und OpenAL und war an der Entwicklung sowohl der Grafik- als auch der Physik-Engine für das Spiel Söldner 2 beteiligt. In regelmäßigen Abständen veröffentlicht er auf seiner Webseite Artikel und Tutorials über den Einsatz des modernen Vulkan-API sowie der OpenGL-Spezifikationen 3.x und 4.x und ist als freier Mitarbeiter im Bereich 3-D-Programmierung tätig. Seine E-Books 'Spieleentwicklung - Mathematik mit Fun-Faktor' und 'Spieleentwicklung - OpenGL mit Fun-Faktor' vermitteln Einblicke in die Welt der Spieleprogrammierung.

1 Entwurf eines einfachen Frameworks

Vulkan [1], [2], [3] bietet nie dagewesene Möglichkeiten und Freiheiten zum Preis einer im Vergleich zu OpenGL deutlich komplizierteren Handhabe. In Anbetracht dieser Tatsache dürfte es daher auch niemanden verwundern, dass die praktische Arbeit mit einem Low-Level-API wie Vulkan ohne Zuhilfenahme eines geeigneten Frameworks schnell zu einem mühevollen Unterfangen wird. Es gibt jedoch noch einen weiteren Grund, warum wir uns so früh wie möglich mit dem Entwurf eines eigenen Frameworks befassen sollten: In der Entwurfsphase können wir uns mit sämtlichen Aspekten des neuen Vulkan-API vertraut machen, ohne dass wir uns gleich in alle Details der zugrunde liegenden Programmabläufe einarbeiten müssen.

Im ersten Teil dieser shortcut-Reihe haben wir uns mit den Voraussetzungen befasst, unter denen die neue Vulkan-Schnittstelle ihre Vorteile gegenüber dem mittlerweile etwas in die Jahre gekommenen OpenGL-API voll ausspielen kann. Vorbei sind die Zeiten, in denen bei der Entwicklung einer Grafikanwendung sämtliche mit OpenGL in Verbindung stehende Programmabläufe innerhalb eines einzigen Threads implementiert werden mussten. Rendering-Operationen, Buffer- und Ressourcenupdates (Austausch der nicht mehr benötigten Texturen und 3-D-Modelle) sowie die mitunter erforderlichen Compute-Shader-basierten Berechnungen lassen sich im Verlauf der Vulkan-Programmentwicklung im Prinzip auf eine beliebig große Anzahl von Threads aufteilen. Damit die einzelnen Threads jedoch auch wirklich parallel zueinander ausgeführt werden können, muss man als Entwickler dafür Sorge tragen, dass sich die Anzahl der Threads an die jeweils zur Verfügung stehende Hardware anpassen lässt.

Doch auch an dieser Stelle ist Vorsicht geboten: In der Theorie ist es zwar korrekt, dass beispielsweise auf einer 8-Kern-CPU acht Threads parallel ausgeführt werden können, allerdings sollte man stets in Erinnerung behalten, dass sowohl das Betriebssystem als auch weitere Anwendungen ein gewisses Maß an Rechenzeit für sich selbst in Anspruch nehmen. Darüber hinaus ist es zwingend erforderlich, eine mehr oder weniger große Zahl von Threads für Programmabläufe zu reservieren, die zwar nichts mit der eigentlichen grafischen Darstellung zu tun haben, für deren Ausführung jedoch innerhalb des Hauptprogrammthreads schlicht zu wenig Zeit zur Verfügung steht. Hierzu zählen unter anderem KI-Berechnungen, Physiksimulationen, Kollisionsberechnungen, mögliche Interaktionen mit der Spielewelt, die Musik-, Sound- und Sprachausgabe oder die prozedurale Generierung der Spielewelt.

Das Vulkan-API bietet uns darüber hinaus auch die Möglichkeit, die Kommunikation zwischen der CPU und der GPU (der Grafikkarte) an die jeweiligen Anforderungen einer Grafikanwendung anzupassen. Im