Ich wollte mich mal ein bisschen schlau über Vulkan machen und habe danach gegoogelt.
Ist das wirklich so, das man über 500 Zeilen Code braucht, bis man das erste Dreieck hat ?

Hier sogar fast 1000 Zeilen: https://github.com/Overv/VulkanTutorial ... iangle.cpp

Braucht es diesen enormen Overhead, oder geht dies auch einfacher ?

_________________
OpenGL

Leider ist das der Fall, da Vulkan das Speichermanagement, Pipeline und deren Stages dem Entwickler überlässt und sich auf eine Minimale Hardware API konzentriert. Daher funktioniert das so ziemlich überall mit einer Codebase aber man muss ne Menge Code selber mit bringen.
Sascha hatte damals, als es sich etabliert hat, ein Framework gebaut und das pflegt er und wird auch auf andere Sprachen portiert und hat sich als Standard in der Vulkan Szene etabliert.
Wenn man OpenGL 4.5 genutzt hat, dann kennt man das schon zu Teil, weil man dort auch die einzelnen Schritte der Pipeline selber bauen muss, basis Lineare Algebra benötigt und Objekte gibt, die man sinnvoll verwaltet muss aber es gab kein Memory management.

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

Projekte: https://github.com/tak2004

Dann ist wohl nichts, in der schnelle mal ein einfaches Beispiel mit einem Dreieck auszuprobieren.

Mein Ziel wäre, das ich Vulkan unter Lazarus zum laufen bringen.
Es gibt da eine Package pl_Vulkan, aber leider hängen diese alle wen ich sie probieren will.

Dies hatte ich noch gefunden: https://github.com/BeRo1985/pasvulkan
Mit Mühe und Not und Bibliotheken zusammenwursteln habe ich es zum laufen gebracht.
Aber dieses Example ist total überladen.

So wie es aussieht muss ich da zuerst mal passen.


Würde es sich lohnen zuerst mal mit OpenGL 4,5 zu beschäftigen ?
Ich vermute mal, da ist der Schritt ein wenig einfacher, wen man von den OpenGL3.3 Welt kommt.

_________________
OpenGL

Wenn du bei OpenGL erstmal bleiben willst, dann probier 4.5 und eventuell auch die Extension von NV und AMD für Memory Management. Du kannst mit OpenGL4.5 und Extensions ziemlich nahe dem Code kommen, den du für Vulkan brauchst.

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

Projekte: https://github.com/tak2004

Kann man dies etwa so vorstellen ?
Bei OpenGL 1.x waren alle Pipelines fix, Von aussen, hatte man ein paar Zeichen-Befehle und konnte die Matrix ein wenig manipulieren.
Später kamen die Shader dazu, dort musste man die ganze Render-Pipeline selbst programmieren, dafür wurde man mit Flexibilität belohnt.

Und mit Vulkan hat man auf den ganzen Rendering-Prozess Einfluss, auch was das ganze Buffergeschehen anbelangt ?
Und man kann die Grafikkarte voll auf seine eigenen Bedürfnissen programmieren ?

_________________
OpenGL

OpenGL1 hat fixed pipelines, du hast States wie Texturslots, Filter, Vertices und shortcuts für Vertex Arrays aber die Struktur war starr.
OpenGL2 bricht es etwas auf. Shader weniger States. Rudimentäre Shader.
OpenGL3 hat Geometry, Fragment, Vertex, Tesselation shader, also die Schritte in der Pipeline sind immer noch fix aber du kannst die Schritte nun selber modifizieren. States werden weniger, Objekte kommen ins Spiel. Einige stages, in der Pipeline sind nun optional.
OpenGL4 States kommen in Objekten, Objekte überall, Shader sind noch flexibler, GPU seitige Befehl-Pipelines, compute shader, custom debugging.
Als Extensions kamen noch diverse Sachen, z.B. für Memory Management, unterschiedliche Auflösungen beim Swap(glaube swap-chain war der name).
Also die Pipeline ist immer fix aber es gibt viele Optionale Stages.

Mein Verständnis von Vulkan ist dass ich die Pipeline selber definiere aber gewisse Stages benötigst(Fragment shader).
Eventuell haben wir ja wen aktives noch hier, der da mehr zu sagen kann.

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

Projekte: https://github.com/tak2004

So wie ich es vermutet habe.


Aus irgend einem Grund wurde mir dazumal OpenGL 3.3 und nicht die 3.0 empfohlen.
Wurde mir dies gemacht, weil die 3.3 mehr ausgereift war ?


Dies tönt recht spannend.
Ich werde mir Vulkan mal im Hinterkopf behalten.

_________________
OpenGL

Am besten kann man die Änderungen hier sehen.
3.1 hat die alte API entfernt, 3.2/3 haben die Shader stark verändert.
Ich würde direkt auf 4.6 gehen, ich sehe dort, dass SPIR-V supported wird, dass benötigst du für Vulkan. Das ist ein llvm basierter Shader compiler. Der wurde bei AMD auch schon vor 4.6, hinter den Shader compiler verwendet.

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

Projekte: https://github.com/tak2004

Für OpenGL 4.6 wird es wohl schwer sein, eine Lektüre zu finden.
Für die 4.5 gibt es die dicke Bibel. Und in diese hat es auch SPIR-V.

https://www.amazon.de/OpenGL-Programmin ... 112&sr=8-2

_________________
OpenGL

Ich hatte die Kindle Variante genutzt. Die war gut.

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

Projekte: https://github.com/tak2004

Ich habe ein PDF gefunden.

Da habe ich folgendes gewurstel gesehen,

Ich denke, die kann man sicher eleganter mit einem Record lösen.
Bei OpenGL 3.3 ging dies beim UBO auch,

Aber ich vermute mal, im Buch machen die es so, um zu zeigen, wie man die Offsets und Grössen im Uniform-Struct auslesen kann.

_________________
OpenGL

Wahrscheinlich, je kompakter und sauber aligned, float/half float, des so flinker ist das ganze.
Wir hatten damals für ein Terrain die xyz,uv durch Höhe1,Höhe2,AtlasOffset ersetzt und dann im Vertex Shader über die VertexID x,y, sowie mit AtlasOffset noch u,v errechnet, dann über Distanz zur Kamera die Gewichtung zwischen Höhe1 und Höhe2 errechnet und somit ein LOD gehabt, was zwischen den LOD-Stufen das Mesh morphed. Das ganze passt in 3 floats. Die Macht von custom Data
Heute schätze ich mal, nutzt man eher Geometry Shader und tesselation.

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

Projekte: https://github.com/tak2004

Kleine Korrektur: Tesselation (Control/Evaluation) Shader kamen erst mit OpenGL 4.

_________________
So aktivierst du Syntaxhighlighting im Forum: [code=pascal ][/code], [code=cpp ][/code], [code=java ][/code] oder [code=glsl ][/code] (ohne die Leerzeichen)

Im Übrigen bietet die Mesamatrix meiner Meinung nach einen guten Überblick, welche Extensions wann in den Kern von OpenGL aufgenommen wurden – inklusive Link zu deren Spezifikation, die immer auch einen einleitenden Abschnitt enthält, worum es überhaupt geht.

Du brauchst kein Buch für irgendeine spezielle OpenGL-Version. Seit OpenGL 3.2+ (Core Profile) ist keine Funktionalität weggefallen. Und das Prinzip, wie man OpenGL programmiert hat sich nicht verändert. Es lohnt sich natürlich, die neueren Features zu kennen, so dass man sie einsetzen kann, wenn man sie braucht. Und das ist alles hervorragend in der Spezifikation, bzw. etwas nutzerfreundlicher im Khronos-Wiki dokumentiert.

_________________
So aktivierst du Syntaxhighlighting im Forum: [code=pascal ][/code], [code=cpp ][/code], [code=java ][/code] oder [code=glsl ][/code] (ohne die Leerzeichen)

Der einfache Tesselation-Shader scheint es sogar unter OpenGL 3.3 gegeben zu haben.
Nur konnte man diesen nur auf 3-Ecke anwenden, ab 4.x ist es auch mit Rechtecken möglich,

Ab 4.0 hat es schon noch ein paar interessante Ergänzungen gegenüber 3.3.

_________________
OpenGL