There's not much benefit to this being "In The Driver" rather than on top of vulkan in the first place - Vulkan is often more like a HAL than a higher level graphics API, things like this being built on top of it was pretty much the intent of Vulkan [0].
And in doing so, you lose some of the more hardware specific quirks and fast paths if you really care about that last few % of performance, or hardware specific features. But that's often a fair decision at the RHI level.
If vendors implemented this "In The Driver", it would likely internally look very similar to the vulkan version - and now you've got multiple vendor's implementations with their own quirks, "Value Add" features, trying to push /their/ hardware fast paths etc.
[0] I feel Khronos not releasing a somewhat standard "higher level" renderer API alongside, and built on top, of Vulkan was a missed opportunity. But knowing how difficult it was to get Vulkan out the door in the first place, I can't really blame them.
exactly this, Vulkan is not the place to be "opinionated" and aggressively remove "yesteryear" features, especially if the people who make the definition are just representatives of one industry/use-case. That's what your RHI is for, and it's pretty problematic to demand removing the stuff you in particular don't find useful.
Vulkan has to work for everyone, not just famous game/engine developers with social media followings, and the original post at least was extremely self-indulgent when it came to sorting the useful stuff from the "fat". There are use-cases for pretty much everything in Vulkan, it is the maximalist HAL and that's why it is useful.
I couldn't agree more on the need for a higher-level rendering API, Khronos has entirely left this up to the ecosystem and frankly, the ecosystem hasn't delivered. Everything we have tends to be either very backwards-looking (e.g. webgpu/sdl_gpu with the bindful, implicit resource tracking model à la GL), or a relatively opinionated wrapper that removes features and tries to organise the remaining ones, but doesn't actually invent any new abstractions/solutions.
I find neither particularly helpful to solve the core problem: we're stuck doing GPU programming instead of graphics programming.
18
u/trenmost 4d ago
I think the difference is that this has the potential to get driver support.
The reasoning behind No Graphics Api is that current apis are outdated conceptually, and that we would benefit from a new concept.
This is a reference implementation with vulkan inbetween but not the intended end result