OpenGL Vulkan-Spezifikation veröffentlicht

[Schrompf]

Die Khronos-Truppe hat gestern die Spezifikation zur lange erhofften neuen Generation von OpenGL, genannt "Vulkan", veröffentlicht. Die Spec und eine Menge Kontextinfo und ein paar Demos finden sich auf der neuen Vulkan-Startseite https://www.khronos.org/vulkan/ Um als gestandener Grafikprogrammierer einen Überblick über die neue Welt zu bekommen, lohnt sich dieser hochsubjektiv geschriebene Beitrag: http://renderdoc.org/vulkan-in-30-minutes.html

--- Persönliche Meinung:

Geil. Denke ich jedenfalls. Ich habe die Nase voll vom Wegabstrahieren grundverschiedener Ansätze in den 3D-APIs, die doch eigentlich alle ähnlich ticken sollten, weil die Hardware darunter identisch ist. Vulkan könnte ob seines Scopes an unterstützten Endgeräten und Betriebssystem die finale Lösung sein. Und zumindest die Startseite behauptet, dass auch ewige Desktop-Verunglimpfer wie Intel schon Treiber-Support haben. Die Einstiegshürde ist natürlich brachial - hier muss man alles selbst machen und bekommt auch die kompletten Zeitverhalten transparent durchgereicht. Nix mehr mit glBufferData() in jedem Frame und den Treiber ausknobeln lassen, was wann mit dem bisherigen Inhalt des Buffers passieren soll.

Spannende Zeiten. Evtl. ist die Einstiegshürde aber für meine antizipiert knappe Freizeit zu hoch und ich überlasse das Renderer-Coden in Zukunft den Leuten, die dafür bezahlt werden :-(

[Jörg]

[...] die doch eigentlich alle ähnlich ticken sollten, weil die Hardware darunter identisch ist.

Vulkan zielt nicht nur auf 'identische' HW ab - es bietet auch Moeglichkeiten die mobilen, und architekturmaessig doch verschiedenen, GPUs besser auszunutzen, ohne sich mit unkonventionellen Erweiterungen wie FramebufferDiscard, FramebufferMultisample oder PixelLocalStorage herumzuschlagen.
Es war ein wirklich guter Schritt von Khronos, hier ein paar alte Zoepfe abzuschneiden und neue Wege zu gehen.

Druecke jedem die Daumen der sich daran versucht - Moeglichkeiten zum in die Fuesse schiessen gibt's genug ;)
Man sollte regen Gebrauch der (verfuegbaren) Validierungsschichten machen.

Joerg

[kimmi]

Ich bin gespannt, in wie weit sich die neue API durchsetzen wird.

[anonym]

Die Community hier ist ziemlich gealtert. Vor 10a wäre hier der Teufel los gewesen.

[Tiles]

Naja, das Forensterben ist jetzt kein spezielles Problem der Communityalterung. Und trifft so ziemlich jedes andere Forum genauso. Youtube, Facebook, Reddit und Co haben halt einen gewaltigen Einfluss auf die Art wie Community heutzutage stattfindet. Wer seine Tutorials auf Youtube findet und seine Gedanken zur Welt schon getwittert hat hat meist wenig Lust auch noch in ein Forum einzusteigen. Zumal ZFX schon immer eine eher kleinere Community war. Und die ehemaligen Developianer fast alle abgewandert sind. Siehe spieleprogrammierer.de

[Matthias Gubisch]

Viele sind halt auch hier zu der Einsicht gekommen dass man mit einem kleinen Team oder gar als Einzelkämpfer nur sehr schwer eine State of the Art Engine samt Spiel auf die Reihe bekommt. Was erklärt warum hier nicht gleich der Teufel los ist wegen der neuen API.
Ich denke auch dass sich im Hobby und SemiProfessionellen Bereich neben den Fertigen Engines auch noch Dx11 und OpenGL etwas halten werden.
Dx12 ist ja qasisi das gleiche wie Vulkan.

Zur API an sich kann ich nach den ersten Gehversuchen sagen dass man tatsächlich alles selber machen muss und am Anfang erstmal vieles ungewohnt ist und man so manches vergisst dass einem der Treiber bisher abgenommen hat.
Die ganzen Validierungsschichten sind allerdings recht hilfreich und sollte zu Debugzwecken echt genuzt werden da sie zum Großteil ganz brauchbare Hinweise geben was fehlt oder falsch ist.
Insgesamt hat es mich ein ganzes Wochenende gekostet überhaupt das erste Dreieck auf den Bildschirm zu zaubern.

[Schrompf]

Nunja... zum Einen sind alle hier jetzt wesentlich erwachsener - die Bekehrungsversuche und Verunglimpfungen sind nun deutlich subtiler :-) Und zum Anderen hat sich die Welt halt seitdem heftig weitergedreht - weg von der eigenen Software hin zu fertigen Komponenten. Spannend finde ich die Entwicklung immernoch, nur ist das alles etwas weggerückt.

[Krishty]

Jetzt werden die Treiber bestimmt endlich einfacher weil wir direkt mit der GPU arbeiten!

In some cases, the in-memory layout of data is different for optimal rendering and reading via the texture units. By analyzing the data dependencies that an application provides, our drivers can decide when it is best to perform layout changes, decompression, format conversion and so on. It can also split some of these operations into phases, interleaving them with application-supplied rendering work, which again, eliminates pipeline bubbles and improves efficiency.

(via @nothings)

[Jörg]

In gewisser Weise stimmt das schon - der Treiber spart sich Laufzeitheuristiken. Sub-Pass Abhängigkeiten werden einmalig und sehr explizit beschrieben, vor ihrer (hoffentlich wiederholten) Verwendung.

[Krishty]

Jetzt wo alles von Hand synchronisiert werden muss, werden no-op-Renderings eigentlich immernoch wegoptimiert?

D3D 11 wartete immer auf das finale Present(), baute dann einen Abhängigkeitsbaum mit allen zuvor abgeschickten Befehlen auf, übersprang alles ohne Wirkung (doppeltes Clear(), in Textur gerendert aber nie benutzt). Hat mich in den Wahnsinn getrieben, weil ich gern Operationen über Frames verteilen wollte, aber die Runtime nickte das einfach als no-op ab und wenn ich das Ergebnis endlich brauchte, ging für zwei Sekunden der Lüfter …

Fällt das unter die eingesparten Laufzeitheuristiken? Wird da jetzt endlich nur noch dem Entwickler vertraut?

[Jörg]

Geliefert wie bestellt - sollte man bei Vulkan annehmen. Abhängigkeiten müssen sehr explizit beschrieben werden, inklusive unter der Verwendung von Barrieren. Da ein Vorteil von Vulkan die Verringerung der CPU-Last ist/sein sollte wird man die hoffentlich nicht so bald in Laufzeit-Treibermagie reinvestieren. Das sind ja am Ende Kosten die auch für gute Applikationen anfallen.
Da sogar an Fehlererkennung gespart wird (und das in optionale höhere Schichten auslagert), wird man eine ganze Weile mit dummen aber dünnen Treibern leben können. Wer hier müssen sagt kann ja zu bequemeren APIs greifen ;)

[Krishty]

Super! Mittlerweile freue ich mich ja wirklich, das endlich einsetzen zu können … :) („können“ aus Zeitgründen – Treiber sind ja da, und einmal im Leben habe ich sogar kompatible Hardware :D )

[Jörg]

Jetzt gibts die Tools und den GLSL->SPIRV Compiler auch beim GitHub: https://github.com/KhronosGroup/.
Und noch ein paar mehr Extras von LunarG: https://github.com/LunarG/.