spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ich freu mich schon aufs ausprobieren und selberschreiben.

Na endlich!

Was ist ein guter Grund, sich Vulkan anzuschauen, so als Hobby-Entwickler, der mit vorherigen APIs (DX11, OpenGL 4) auch gut zu Rande kam? Einige was mir einfällt, sind große Engines Performance-Gewinne und eventuell endlich mal eine vernüftige, voll Multithreading-Fähige API.

Die Grundidee ist wohl, einige ehemaligen Abstraktionen abzuschaffen und näher an der Hardware zu sein. Du hast also mehr Möglichkeiten, es ist aber auch komplizierter / aufwändiger. Im Grunde hast du eine Ebene mehr auf der du Entwickeln kannst (im Sinne von Level->Mod->GameMaker->OpenGL->Vulkan) und kannst überlegen, ob du lieber schneller voran kommen willst, oder lieber mehr von der Technik sehen und volle Kontrolle haben willst.

Andererseits ist Vulkan aber wohl auch die Zukunft von OpenGL, und man wird es dann für alles Neue brauchen.

Aber wo man jetzt eine Stufe tiefer gegangen ist, kann man natürlich neue Abstraktionen schaffen. Vermutlich gibt es in ein paar Jahren eine schöne Auswahl an Middleware die man benutzen kann.

Ich persönlich bleibe mindestens fürs nächste Projekt noch bei OpenGL. Seit man Shader hat, hat man da ja eh nahezu unbegrenzte Möglichkeiten.

Abstrakt betrachtet finde ich Vulkan geil. Es ist eine sehr unmittelbare API, die auch das komplette Zeitverhalten transparent an den Coder durchreicht. Das macht es zum Einen sehr praktisch, um große Ressourcen-Mengen ohne Aussetzer an die GPU weiterzureichen - Streaming oder komplexe Algorithmen. Oder man kann damit saftige Teile seines Renderablaufs komplett vorskripten. Ganz zu schweigen von den phantastischen Möglichkeiten der parallelen Programmierung.

Zum Anderen muss man als Programmierer plötzlich an viele absurde Sachen denken, die einem bisher die Treiber abgenommen haben. Nix mehr mit glBufferData() in jedem Frame und der Treiber kümmert sich, was wann mit dem bisherigen Inhalt passiert. Wir werden einen großen Haufen Reinvented Wheels bekommen, wenn jeder Engine-Coder da draußen seine eigene Version eines Multibuffers baut, um weiter jedes Frame die Framerate in die Bildschirmecke zu pinseln. Und wenn man dabei was verkackt, wird man keinen Crash und nix bekommen, sondern komisch flackernde FPS-Anzeigen, die jedes fünfte Frame einmal bildschirmfüllend Datenmüll präsentieren.

Leicht übertrieben formuliert.

Ich persönlich finde es spannend und würde mich darin gern austoben. Für den Moment werde ich aber erstmal weitermachen wie bisher, und das ist bei mir aktuell immernoch DX9/OGL3. Und in Anbetracht meiner stark schwindenen Freizeit in den nächsten Jahren wäre es eigentlich klug, das Engine-Coden komplett anderen Leuten zu überlassen. Schade.

Zitat von »Schrompf«

Das macht es zum Einen sehr praktisch, um große Ressourcen-Mengen ohne Aussetzer an die GPU weiterzureichen - Streaming oder komplexe Algorithmen.

Das halte ich auch für ein großes Problem der "alten" APIs.

Zitat von »Schrompf«

Und wenn man dabei was verkackt, wird man keinen Crash und nix bekommen, sondern komisch flackernde FPS-Anzeigen, die jedes fünfte Frame einmal bildschirmfüllend Datenmüll präsentieren.

Das mag sein, soweit ich das aber verstanden habe, haben Spielekonsolen solche Low-Level APIs schon lange, somit sollte da hoffentlich genügend Erfahrung rüberschwappen, dass das nicht sooft passiert. Hoffe ich.

Zitat von »Schrompf«

Und in Anbetracht meiner stark schwindenen Freizeit in den nächsten Jahren wäre es eigentlich klug, das Engine-Coden komplett anderen Leuten zu überlassen. Schade.

Amen.

Also ich sehe in Vulkan auch die Change, dass vieles einfacher wird.
Ganz besonders in der OpenGL Welt.

Zum Erstellen eines Context braucht man eigentlich eine eigene Lib. Wenn man einfach so GLSL Code schreibt, kann man sicher sein, dass er auf einem anderen Treiber (ggf. sogar bloß anderer Version) gar nicht erst kompiliert. Außerdem gibt es momentan einfach unendlich viele Möglichkeiten um das selbe zu erreichen. Und dann gibt es DSA. Aber auch DSA als Extension oder manchmal gar kein DSA. Bereits jetzt lässt sich OpenGL ohne zig Libs im Moment kaum sinnvoll verwenden.

Häufig ist nicht klar, welche API die richtige Wahl ist:
Nimmt man jetzt ein UBO, ein SSBO, eine Texture Object? Noch ein anderes Beispiel: Wie lädt man am Besten viele Daten hoch? Mit glBufferData? Oder doch lieber mit glBufferSubData? Oder lieber mappen mit glMap? Ist Unsynchronized Zugriff wirklich schneller? Solche Entscheidungen sind nicht bloß nervig, sondern bei größeren Datenmengen auch sehr schwierig. Die Performance ist sehr stark vom Treiber abhängig, unstabil und nicht vorherzusagen. Solche Entscheidungen könnten mit Vulkan überflüssig werden, da die Unterschiede in bisherigen APIs überwiegend im Treiber entstanden.

Command Buffer bzw. Pipeline Objekte scheinen mir auch ein Segen zu werden. Verschiedene Komponenten brauchen oft verschiedene Zustände. Momentan ist das sehr kompliziert zu erreichen. Meist muss man alle States selbst verfolgen und wieder manuell zurückzusetzen. Leicht ändert man an einer Stelle mal etwas, aber der alte State wurde leider an einem anderen weit entfernten Ort noch implizit vorausgesetzt. Schrecklich. Mit einem Pipeline Objekte wird einmal zum Programmstart für eine Komponente klar definiert, welche States später immer gebraucht werden. Das sollte sehr viel praktischer sein.

Die Sache mit der Synchronisation wird in Vulkan wohl etwas schwieriger. Allerdings muss man für Performance jetzt auch schon praktisch alles in wenige zyklisch geupdatete Buffer-Objekt zusammenpacken und den Speicher innerhalb selbst verwalten. Ich die Hoffnung, dass ich durch die modernere API, die Debug-Funktionen und durch das klarere Ausdrücken meiner Intention an den Treiber insgesamt wesentlich schneller ans Ziel komme als zuvor.

Also gegenüber OpenGL wird bestimmt einiges eher einfacher. Aber vieles von deinem Text trifft auch auf den Vergleich OpenGL vs DirectX zu.

Zitat von »Legend«

Aber vieles von deinem Text trifft auch auf den Vergleich OpenGL vs DirectX zu.

Welche Teile denn genau? DirectX ist wie OpenGL eher highlevel angelegt und versteckt insbesondere das Zeitverhalten gut. Im Gegensatz zu OpenGL ist DirectX allerdings sehr viel verlässlicher und weniger ein Maintenance-Albtraum je nach Kombination von Vendor/OS/Treiberversion. Und die Tools für DirectX sind einfach mal Meilen besser als alles, was es für OpenGL gibt. Auch wenn sich das in den letzten Jahren mit NSight und Konsorten etwas gebessert hat.

Dass Vulkan jetzt eine Intermediate Assembly für Shader festlegt, ist schonmal ein großer Schritt in die richtige Richtung. Endlich Shader plattformabstrakt vorkompilieren und verifizieren. Wenn die Tools mithalten und der Treiber-Support zuverlässig funktioniert, wär das ein großes Ding.