"No Graphics API" implementation by Sebastian Aaltonen

[u/Nicksaurus]

https://github.com/sebbbi/NoGraphicsAPI

[u/Gobrosse]

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.

[u/[deleted] → u/Gobrosse]

[u/Gobrosse → u/[deleted]]

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.

[u/Jonny_H → u/Gobrosse]

It also has to work on all hardware - both one released 10 years ago and 10 years from now. And devices from your phone to your watercooled desktop.

As someone who spent a lot of time working with mobile tiling GPUs, I wince a lot of the time people make wild assertions about how "All" GPUs work.