Which are? (I'm genuinely interested)
Followed by Khronos refusal that it isn't part of their job to define an SDK, so each newbie has to go through the ritual of passage to learn how to get OS abstraction libraries to show up a 3D accelerated window, math library, font handling library, texture and image loading library, shader compiling infrastructure, scene graph to handle meshes,....
Now there is LunarG SDK, which still only offers a subset of these kind of features.
If it wasn't for NVidia's early C++ efforts, Vulkan would still be C only.
Also Vulkan only exists because AMD was so kind to contribute Mantle as starting ground, otherwise Khronos would most likely still be arguining how OpenGL vNext was supposed to look like.
Really, in 21st century if you want to write portable 3D code just use a middleware engine, with plugins based backend.
Vulkan isn't for newbies. Really, if you're new to 3D graphics then you're not Vulkan's target audience; pretending otherwise only results in pain. That's like complaining that a modern CPU's privileged instructions are too complicated for people new to assembly – yes, they are, and no, that's not a design flaw.
> Also Vulkan only exists because AMD was so kind to contribute Mantle as starting ground
That's maybe a point against Khronos, not against Vulkan.
> Really, in 21st century if you want to write portable 3D code just use a middleware engine, with plugins based backend.
Which is exactly what people should be doing. And those middleware engines can be written using Vulkan, because it is designed the way it is.
Yet that doesn't mean I don't care about newbies in 2021, specially when Khronos says OpenGL isn't going to move beyond version 4.6, thus everyone new in the field feels like Vulkan is what they should learn instead.
Isn't this why Vulkan was designed the way it was. It's lower level, giving more control to things like memory. In this way I view it somewhat like the ASM of the GPU (even though though there are lower levels still).
I'm curious if anyone with a lot of experience writing graphics "middleware engine" backends agrees.
The companies who have these resources (for instance the GPU vendors), chickened out by designing Vulkan and thus offloading those QA tasks to the API users (simplified, but that's what it is in the end).
Which leaves Unity, Epic, and a handful AAA game developers as potential Vulkan users, which in turn are not enough to test Vulkan implementations, because just a handful API users isn't enough to cover all the dusty corners (same situation as back in the bad old days with MiniGL).
Extensions are a PITA to deal with, but they generally represent real disparate hardware features offered by individual GPUs which varies by manufacturer, model, and date. This reminds me of CPU features like SSE2, AVX, AES, etc, etc which general-purpose binary programs are forced to query for at runtime to either take advantage of or fall back to a software implementation. But GPUs have even more architectural change velocity than CPUs.
It seems like a hard problem in general. How do you think this could be done better?
With extension spaghetti, not only are we back in GLAD and GLEW land, each set of extensions is yet another possible code path.
That seems to me like a reasonable decision that graphics API does not try to encompass and duplicate many other unrelated APIs and stays focused on graphics.
Immediate mode OpenGL not even a particularly friendly API, either. I found its implicit global mutable state for things like the matrix stack to be deeply confusing. There's much better drawing libraries out there if what you're looking for is ease-of-use.
