Ja, es ist mehr Aufwand. Das liegt in der Natur einer expliziten API. OpenGL hat ganz viel weggekapselt. Wenn man schnell mal was in 3D machen will ist das besser, aber man ist ganz weit weg von der Hardware und hat keine explizite Kontrolle darüber wann was passiert.

Das ist mit Vulkan ganz anders. Aber Vulkan ist auch nicht für jeden, und wird OpenGL auch nicht ersetzen. Wer also als Hobby ein wenig 3D Programmierung machen will kann bei OpenGL bleiben.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Sprich, Vulkan muss auch noch irgendwie gekapselt werden, wenn man es wie OpenGL bzw in einfacher Art und Weise nutzen will.
-> OpenGL(Vulkan) oder Framework(Vulkan)

Ja, man sollte zumindest die grundlegensten Sachen kapseln. Hab ich in meinen Demos ja auch gemacht, außer beim Dreieck. Siehe den vkTools::initializers Namespace in https://github.com/SaschaWillems/Vulkan ... ntools.cpp

Zu viel abstrahieren sollte man nicht, und schon garnicht versuchen Vulkan so umzubiegen dass es wie OpenGL aussieht.

Der große Vorteil ein Vulkan ist der geringere CPU-Overhead und die Multi-Threading Fähigkeit, und das sollte man dann auch nutzen.

Von NVIDIA gibts zumindest ne C++ API die zeigt wie man beim Kapseln vorgehen kann : https://github.com/nvpro-pipeline/vkcpp

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Wenn man es zu sehr kapselt, wird man wahrscheinlich die Performancevorteile wieder verlieren, oder warum meinst Du?
Sind eigentlich auch signifikante Performancevorteile auf der GPU zu verzeichnen oder macht es sich nur bezüglich der CPU-Zeit bemerkbar?
Kommt eigentlich auch irgendwann ne neue OpenGL-Version raus bzw. neue Extensions?
Eine Extension, die Spir-V in OpenGL ermöglicht, fänd ich gut. Ist das realistisch in nächster Zeit?

_________________
"Pixel, ich bin dein Vater."
-Darf Shader

Die API-Architektur ist näher an der GPU und man hat feinere Kontrolle über Synchronisierungsprozesse. Ein Beispiel ist z.B. das Stagen von Buffern. D.h. man holt sich zuerst einen Buffer mit Host-Sichtbarkeit (Staging), schiebt dort die Daten rein und kopiert diese dann in einen Bereich den nur die GPU sieht. Die kann dann maximal optimieren. Also ja, wenn die Treiber ausgereift sind dann dürfte man auch etwas mehr Leistung aus der GPU rausbekommen. Aber der Hauptteil des Zuwachses liegt woanders. Also Multithreading, Pipeline caching (kann man direkt von der Platte laden), etc.

Gegenüber OpenGL mit AZDO wird man aber rein in Richtung GPU kaum Geschwindigkeitsvorteile sehen.


Ja, OpenGL wird weiterentwickelt.


Diese wird es definitiv geben. Die IHVs die Vulkan unterstützten haben jetzt ja alle SPIR-V im Treiber umgesetzt, den nach OpenGL zu porten sollte nicht zu schwierig sein.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Das sollte eigentlich schon der Fall sein, da die letzte glsl version und opencl darauf laufen.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Bin mal auf die erste virtual texture implementierung gespannt. Mit der vollen Kontrolle über die pipeline sollte man das noch besser als sparse texture hin bekommen, da man nicht so ein generisches konstrukt benötigt.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Hab grad ein wenig über AZDO gelesen, wusste ja gar nicht, dass man mit OpenGL jetzt auch multithreaden kann.
Bin auch auf diesen Benchmark gestoßen:
https://developer.nvidia.com/vulkan-ope ... ene-sample

Da sieht es so, als ob man ob man mit NV_command_list auch die CPU-Zeit sehr gut hinbekommt.
Gibt es sowas auch für AMD, bzw. wird es das geben?

_________________
"Pixel, ich bin dein Vater."
-Darf Shader

In progress https://github.com/MaksymTymkovych/Delphi-Vulkan

Ich hab über die letzten Tage ein paar Bugfixes in mein Vulkan Repo gepusht. Die Beispiele laufen jetzt auch alle auf AMD GPUs, da haben hier und da noch ein paar image barriers gefehlt

Aktuelle Windows Binaries gibt es hier, bitte beachten dass man dafür aber den data-Ordner aus dem Repo braucht, da dort Shader, Modelle, etc. liegen.

Am 8.April gibts übrigens ein Meetup vom Khronos Chapter in München. Wer in der Nähe ist und sich was über Vulkan anhören möchte kann ja mal reinschauen. Das ganze findet bei AMD statt, und ich bin auch da

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Für Intel GPUs habe ich hier : https://gist.github.com/SaschaWillems/4 ... e99a3d30e1

Mal kurz zusammengefasst wie man unter Linux den aktuellen Intel Mesa Vulkan Treiber kompiliert und einrichtet, einen Report dazu habe ich hier hochgeladen.

Ganz praktisch wenn man nicht grade am Desktoprechner ist, und z.B. nur ein Ultrabook mit integrierter Intel GPU hat. Der Treiber ist kompletter als der aus dem LunarG SDK und unterstützt u.a. auch transfer auf der graphics pipeline, also blit und copy um z.B. offscreen Rendering zu machen.

Ein Großteil meiner Demos läuft bereits, wobei der Treiber auf den Intel GPUs der 7. Generation noch nicht alles unterstützt.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Ich hab mich die letzten Tage mal mit dem Android NDK-Buildsystem auseinandergesetzt, und die gemeinsame Codebasis bereits soweit umgestellt dass ich alles über den Asset-Manager aus einer APK laden kann. Nachdem ich dann auch endlich eine statische Version von Assimp für armv7 erzeugt bekommen hab bin ich grade fleissig dabei die Vulkan Demos allesamt auch unter Android lauffähig zu machen.

Die ersten paar Beispiele sind schon soweit. Schon toll wenn man mit dem selben Rendercode Android, Windows und Linux bedienen kann. Viel schicker als z.B. OpenGL und OpenGL ES die ja doch unerschiedlich sind

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Nach ein paar Tagen Arbeit laufen jetzt alle meine Vulkan Beispiele auch auf Android :



Was den Rendercode angeht musste ich bei keinem Beispiel Anpassungen vornehmen. D.h. nur die WSI und das Eventhandling mussten für Android angepasst werden. Gamepad-Support war auch recht einfach. Schwierig war nur eine brauchbare statische Version von ASSIMP auf Android zu bauen, aber das hat dann auch geklappt

Fertige APKs gibts dann vermutlich morgen.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Ich hab grade aktuelle Binaries unter http://vulkan.gpuinfo.org/examples veröffentlicht.

Wer also nicht selber aus dem Repo bauen will findet hier ausführbare Versionen meiner Vulkan Beispiele für Windows (64 Bit), Linux (64 Bit) und Android (ARM).

Ich hab gestern auch noch nen kleinen (leider nicht ganz fertigen) GPU raytracer ins repo gepackt (Compute Shader).

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Ich wollte eine probieren, aber ich denke mein PC unterstützt kein Vulkan.

_________________
OpenGL