Vulkan - Nachfolger von OpenGL

Java-Forum Allgemeine Themen
21

Was zur Hölle.
Okay low level, is kla aber… und die Statemachine sind sie auch nicht losgeworden, großartig. -_-
Wer arbeitet nicht gerne mit Statemachines. Klappt bei OGL doch immer so wunderbar.

22

Habe mich mal eingelesen in Vulkan und mir die Präsentationen von NVIDIA, AMD und Intel angehört.
Eigentlich unterscheidet sich Vulkan kaum von OpenGL.
Die Funktionsweise ist die Gleiche, größtenteils sind einfach nur die Befehle gesplittet worden z.B. beim Binding von Ressourcen.
Es gibt noch mehr, aber Grundessenz ist die dass man OGL emulieren indem man einfach alles wieder in Methoden zusammen packt (auch die Logik muss man selber schreiben, natürlich).

Dabei sei auch gesagt: Vulkan unterstützt OGL 4.5 Befehle.

23

Ja, ich hab’ mich auch mal eingelesen, und glaube, dass hier noch ein Tippfehler drin ist.

:o)

(„Einlesen“ ist wohl ein dehnbarer Begriff :smiley: ). Ich denke schon, dass es einige auch konzeptuelle Unterschiede gibt, die sich nur im oberflächlichsten Sinne aus einer PowerPoint-Präsentation ableiten lassen. Aber was fundiertes kann ich aus den nahe liegenden Gründen noch nicht dazu sagen…

24

Webinar. Der Hauptteil ist langweilig. Die Q&A sind nicht schlecht.

Gruß
Fancy

25

Das Logo mit den „4 Klassikern“ (und der böse guckenden Teekanne) ist ja niedlich :smiley: Ich schau’ gleich mal rein, vielleicht ist dann eher absehbar, was sich an Rendering alles ändern muss :smiley:

26

Also soweit ich das mitbekommen habe, fliegen, grob gesagt, bei Vulkan nur OpenGL-Techniken vor OGL 3.0 raus, bzw. weden durch andere ersetzt. So z.B. die prozessorlastigen glVertex, glColor, glTexturCoord, DisplayLists usw. Prinzipiell halte ich das für einen sauberen Schnitt, diese Altlasten, die ohnehin keiner mehr verwenden sollte, loszuwerden.

27

Nein, das wären dann die OpenGL Core Profile. Entscheidend bei Vulkan ist, das die ganze Magie die im OpenGL Treiber steckt ersatzlos weggefallen ist. Stattdessen wird jetzt von der Anwendung erwartet das diese sich explizit um Ressourcenverwaltung und Synchronisation kümmert. Natürlich existiert eine Schnittmenge zu OpenGL, es handelt es sich eben bei beiden APIs um eine schnelle Rasterisierung von Dreiecken.

Ein ehemals einfaches

        glBindBuffer(GL_ARRAY_BUFFER, vboHandle);
        glBufferData(GL_ARRAY_BUFFER, buffer, GL_STATIC_DRAW);
        glEnableVertexAttribArray(VERTEX_LOCATION);
        glVertexAttribPointer(VERTEX_LOCATION, 3, GL_FLOAT, false, 6 * Float.BYTES, 0);```

wird dann zu

const VkBufferCreateInfo buf_info = {
.sType = VK_STRUCTURE_TYPE_BUFFER_CREATE_INFO,
.pNext = NULL,
.size = sizeof(vb),
.usage = VK_BUFFER_USAGE_VERTEX_BUFFER_BIT,
.flags = 0,
};
VkMemoryAllocateInfo mem_alloc = {
.sType = VK_STRUCTURE_TYPE_MEMORY_ALLOCATE_INFO,
.pNext = NULL,
.allocationSize = 0,
.memoryTypeIndex = 0,
};
VkMemoryRequirements mem_reqs;
VkResult U_ASSERT_ONLY err;
bool U_ASSERT_ONLY pass;
void *data;

memset(&demo->vertices, 0, sizeof(demo->vertices));

err = vkCreateBuffer(demo->device, &buf_info, NULL, &demo->vertices.buf);
assert(!err);

vkGetBufferMemoryRequirements(demo->device, demo->vertices.buf, &mem_reqs);
assert(!err);

mem_alloc.allocationSize = mem_reqs.size;
pass = memory_type_from_properties(demo, mem_reqs.memoryTypeBits,
                                   VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT,
                                   &mem_alloc.memoryTypeIndex);
assert(pass);

err = vkAllocateMemory(demo->device, &mem_alloc, NULL, &demo->vertices.mem);
assert(!err);

err = vkMapMemory(demo->device, demo->vertices.mem, 0,
                  mem_alloc.allocationSize, 0, &data);
assert(!err);

memcpy(data, vb, sizeof(vb));

vkUnmapMemory(demo->device, demo->vertices.mem);

err = vkBindBufferMemory(demo->device, demo->vertices.buf,
                         demo->vertices.mem, 0);
assert(!err);

demo->vertices.vi.sType =
    VK_STRUCTURE_TYPE_PIPELINE_VERTEX_INPUT_STATE_CREATE_INFO;
demo->vertices.vi.pNext = NULL;
demo->vertices.vi.vertexBindingDescriptionCount = 1;
demo->vertices.vi.pVertexBindingDescriptions = demo->vertices.vi_bindings;
demo->vertices.vi.vertexAttributeDescriptionCount = 2;
demo->vertices.vi.pVertexAttributeDescriptions = demo->vertices.vi_attrs;

demo->vertices.vi_bindings[0].binding = VERTEX_BUFFER_BIND_ID;
demo->vertices.vi_bindings[0].stride = sizeof(vb[0]);
demo->vertices.vi_bindings[0].inputRate = VK_VERTEX_INPUT_RATE_VERTEX;




Und das gehört definitiv zu den einfachen Dingen. An der API selbst finde ich bisher noch keinen Gefallen. Mir sind das definitiv zu viele Structs und Callbacks.

Gruß
Fancy
28

Naja… Ich kann mir bei Leibe nicht vorstellen, dass es so angedacht ist. Zumindest war es in so ziemlich jeder neuen API bisher immer reichlich sinnbefreit, wenn man einen Anwender komplett aus der Simplizität und Routine einer älteren verdrängt und dabei (außer ellenlangen Code für die einfachsten Dinge) nicht wirklich etwas Neues bietet. Normalerweise stampft man solche neuen APIs ein und redet nimmer drüber.

29

Im Webinar gibt es dazu passend zwei Folien:

Gruß
Fancy

30

Inzwischen poppen ja auch weitere Beispiele auf, z.B. das „Einzelne Dreieck“ nach dem ich gefragt hatte:
https://github.com/SaschaWillems/Vulkan/blob/master/triangle/triangle.cpp
So, wie es sein soll: Ohne irgendwelche Pseudo(!)-hilfreichen Helper-Funktionen, sondern einfach so, wie es mit Vulkan eben sein muss).
(Leider bin ich gerade an einer 32bit-Kiste, deswegen kann ich das ganze noch nicht selbst ausprobieren, aber … vielleicht reiche ich für nächste Woche mal Urlaub ein…). Tutorials und Übersichten ( Vulkan in 30 minutes etc) dürfte es auch recht schnell geben.

Und es IST wohl so kompliziert. Die „Rechtfertigung“, die im Webinar zu den geposteten Folien genannt wurde, war ja, dass diese extreme Low-Leveligkeit es erlaubt, flexibler (und ggf. domänenspezifischer) Abstraktionsschichten drumzuwickeln. Das stimmt zwar einerseits, aber es wird schon noch eine Weile dauern, bis sich da etwas rauskristallisiert, wovon mal eine gewisse „Nachhaltigkeit“ annehmen kann…

Die ersten Java-Bindings gibt’s ja auch schon, in LWJGL: https://github.com/LWJGL/lwjgl3-generated/tree/master/java/org/lwjgl/vulkan . Offenbar ist der Codegenerator von „Spasi“ deutlich mehr gestreamlined als meiner. Bei dem hatte ich vor 1-2 Wochen erst ein größeres Refactoring angesetzt. Zwar ist Vulkan jetzt ein netter Testfall, aber es sind immer noch (viel zu) viele manuelle Schritte notwendig, um da das gewünschte rauszukriegen :frowning: und wenn ich mir das von LWJGL so ansehe, ist insbesondere das Struct-Handling deutlich ausgefeilter - von der Interoperation mit „dem Rendering-Window“ (was bei LWJGL ja umsonst dazukommt) mal ganz zu schweigen. Alles in allem wächst das ungute Gefühl, dass das mit JVulkan (speziell im Vergleich zu dem, was es jetzt schon gibt) nichts vernünftiges werden kann :frowning: Hätte wohl mehr Zeit in die Infrastruktur stecken sollen, statt in irgendwelche sinnlosen Drittprojekte. Wie auch immer.