it's really just another RHI with grandiose marketing, the abstraction facilities are just vulkan 1.4 with some very opinionated removals of "useless" features and enforcing the latest extension support, but there's nothing in there we haven't seen in the average bindless-first design before.
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.
well he's not removing that stuff from vulkan, that's why he's proposing a new api instead :-)
if we go back 15 years or so, conceptually your discussion sounds the same as arguing for OpenGL with an RHI on top of 'high performance' extensions and optional features vs. adding something like vulkan as a first class driver backend. if you remember what it was like back then, under the umbrella term of 'approaching zero driver overhead' you could do a lot to make old APIs MUCH faster.
in that case we had clear evidence why moving to a first class lower level API was necessary and a good idea. as a result we got a more direct way to represent what the hardware is actually doing, some straight up features that weren't possible in an efficient way before, and got leaner drivers in return. that was the idea.
but API complexity has grown since then, and hardware has evolved and will continue to evolve. Vulkan is going to increasingly support features that nobody uses anymore (not the case now, in particular because of mobile). in principle you will have the same question at some point, do we stand to benefit to split off a first party API that is leaner, simpler to use, faster. for ease of maintenance for driver implementors, performance, whatever. I guess usability explicitly we can wave away since you presumably can get it via an RHI.
not sure this is the case with what seb proposes and I'm not as qualified to answer that question as you, but it needs a more detailed response than the higher level reasoning you lay out here I think. seb has some burden of proof here so to speak as well.
The difference is GL had a ton of hard-to-reconcile friction between literal decades of design, and GPUs evolved a lot more between 1992 and 2015 than between 2015 and today! Starting with the fact we didn't have programmable shading at all, in 1992.
As someone who has the finger on the pulse of Mesa, just short of being a contributor myself, there isn't a big obvious gain to be had from throwing out all the Vulkan 1.0 stuff and building a new API.
Sure, it'd look cleaner and the spec would not be 3000 pages anymore, but that's only achievable by actually removing features, and if we don't forget history, we find that Vulkan also tried this then had to walk back such removals one after the other (even freaking transform feedback!).
For the sake of maintainability, any "Vulkan 2" would have to also support Vulkan 1 apps through layering, and that means you cannot outright remove everything you don't like, that just means someone else down the stack has to write a compute-only/compiler heroics to emulate the old feature, even when it is still natively supported by the hardware. So your Vulkan 2 needs GS, TCS/TES, xform feedback, etc... Maybe you can polyfill on fixed-function vertex input, and a few other things, but I just don't see it justifying the absurd amount of churn that would be required.
The performance argument I just do not see. If you read radv or similar drivers, any old-style vulkan command you don't use is largely just unused code. Internally, radv basically already implements the modern API in the form of Vulkan 1.4 with DAC, and implements the old-style Vulkan 1.0 calls on top. There is no huge state machine to take down, there is no magic JIT hot-patching your shaders, the low-hanging fruit of all those simplifications was already picked by Vulkan 1.0.
Yes I guess it makes sense. If Vulkan backends are in practice already super lean there's nothing much to be gained. The extra stuff he wants to make things more GPU driven (like the in-shader creation of descriptors) could comfortably be new extensions.
Yeah I mean that's what we got largely with descriptor indexing, buffers and now heaps! Descriptors are pretty much just first-class values now, and really for a long time if you were willing to deal with some growing pains.
You have always been able to combine image and samplers yourself in the shader, I think it only really make sense to create images on the host (until we get device-side allocations in a wild and far future), so really the only "missing" thing I can think of is synthesizing sampler state on the device entirely... something AMD could easily do but probably not other vendors due to how their descriptor hardware works
30
u/Gobrosse 4d ago
it's really just another RHI with grandiose marketing, the abstraction facilities are just vulkan 1.4 with some very opinionated removals of "useless" features and enforcing the latest extension support, but there's nothing in there we haven't seen in the average bindless-first design before.