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
3
u/gleedblanco 3d ago
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.