Selbst als größter OpenGL-Fan muss man sich irgendwann einmal eingestehen, dass die OpenGL-API mittlerweile ein wenig in die Jahre gekommen ist. Als im Jahr 1992 die OpenGL-Spezifikation 1.0 veröffentlicht wurde, konnte man von massentauglichen Mehrkernprozessoren oder leistungsfähigen Grafikkarten allenfalls träumen. Da selbst so vermeintlich einfache Dinge wie eine Modifikation der Vertexfarbe mit einem nicht zu unterschätzenden Rechenaufwand verbunden waren, war es nur logisch, OpenGL in Form eines globalen Zustandsautomaten (Global State Machine) zu implementieren und die Werte sämtlicher Grafikpipeline-Parameter so lange beizubehalten, bis seitens des Hauptprogramms eine Änderung erfolgte. In der heutigen Zeit, in der die früher üblichen Single-Thread-Anwendungen längst zum alten Eisen gehören, wird diese einstmals vernünftige Design-Entscheidung jedoch mehr und mehr zu einem Problem. Sofern man den kompletten OpenGL-spezifischen Programm-Code innerhalb eines einzelnen Threads (dem sogenannten Rendering Thread) implementiert, ist man auf der sicheren Seite. Die parallele Verwendung mehrerer Rendering Threads im Rahmen einer OpenGL-Anwendung ist hingegen untersagt, da sich sämtliche Zustandsänderungen innerhalb der einzelnen Threads unweigerlich auch auf alle übrigen Threads auswirken würden. Für die Modellierung von Zustandsänderungen, die auf einen einzelnen Thread beschränkt bleiben sollen, ist ein globaler Zustandsautomat schlicht und ergreifend nicht geeignet. Ein weiteres Problem ergibt sich aus der Tatsache, dass man im Rahmen einer OpenGL-Anwendung sämtliche Arbeitsanweisungen auch einzeln an die Grafikkarte (GPU) übermitteln kann. Während sich besagte Anweisungen bei Verwendung eines einzelnen Rendering Threads noch problemlos interpretieren lassen, kann die Reihenfolge der einzelnen Anweisungen bei Verwendung von mehreren Threads vollkommen durcheinander geraten. Wie Sie sehen können, ist der in der breiten Öffentlichkeit hinlänglich thematisierte unverhältnismäßig hohe OpenGL-Treiber-Overhead nicht der einzige Grund, der für einen Wechsel hin zur neuen Vulkan-API spricht. Der größte Vorteil von Vulkan besteht vielmehr darin, dass wir im Unterschied zu OpenGL bei der Berechnung und Darstellung einer 3D-Szene nicht mehr auf einen einzigen Thread (normalerweise handelt es sich hierbei um den Hauptprogramm-Thread) beschränkt sind.Alle hier veröffentlichten Demoprogramme erstellen wir mithilfe eines einfachen Vulkan-basierten Frameworks, welches wir mit jedem neuen Programmbeispiel Schritt für Schritt erweitern werden. Nun denn, verschaffen wir uns mal einen kurzen Überblick über die besonders hervorzuhebenden Features unseres ersten Demoprogramms:
- GPU-basierte Bewegungssimulation sämtlicher 3D-Objekte mithilfe von Compute-Shader-Programmen
- Singlethreaded-Rendering: Für die Erstellung der für das Rendering benötigten Command-Buffer-Objekte ist jeweils nur ein einzelner Thread verantwortlich.
- Multithreaded-Rendering: Die Erstellung eines Command-Buffer-Objektes wird auf mehrere, parallel zueinander ausgeführte Threads aufgeteilt.
- Multithread-basiertes Ressourcen-Management: Verwendung von einem oder von mehreren separaten Threads, um die nicht mehr benötigten 3D-Modelle und/oder Texturen gegen neue auszutauschen.
- Font Rendering
- Deferred Lighting: Beleuchtungsberechnungen im Verlauf der Post-Processing-Phase
- Moderne Szenenkomposition: Verrechnung/Kombination mehrerer Szenen-Teilbilder (z. B. Szenenvordergrund+Szenenhintergrund) im Verlauf der Post-Processing-Phase.
- Offscreen Rendering: Die einzelnen Szenen-Teilbilder, die für die Szenenkomposition erforderlich sind, werden in mehreren separaten Render Targets (Framebuffer-Attachments) (zwischen-)gespeichert.
Download Link: VulkanFrameworkDemo1.zip