Entwurf eines einfachen Frameworks

Besuch auf dem Vulkan

Alexander Rudolph


Im Rahmen des letzten Artikels 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 einfachsten Fall erfolgt die komplette Kommunikation (Rendering-Operationen, Buffer- und Ressourcen­updates sowie Compute-Shader-basierte Berechnungen) über ein einziges VkQueue-Objekt. Das hat jedoch den offenkundigen Nachteil, dass sich die anstehenden Arbeitsanweisungen nur sequenziell an die Grafikkarte übermitteln lassen. Nichtsdestotrotz sollte diese Variante in allen Vulkan-Anwendungen standardmäßig implementiert werden, weil sich hierdurch die Kom...

Entwurf eines einfachen Frameworks

Besuch auf dem Vulkan

Alexander Rudolph


Im Rahmen des letzten Artikels 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 einfachsten Fall erfolgt die komplette Kommunikation (Rendering-Operationen, Buffer- und Ressourcen­updates sowie Compute-Shader-basierte Berechnungen) über ein einziges VkQueue-Objekt. Das hat jedoch den offenkundigen Nachteil, dass sich die anstehenden Arbeitsanweisungen nur sequenziell an die Grafikkarte übermitteln lassen. Nichtsdestotrotz sollte diese Variante in allen Vulkan-Anwendungen standardmäßig implementiert werden, weil sich hierdurch die Kom...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang