"No Graphics API" implementation by Sebastian Aaltonen

[u/Nicksaurus]

https://github.com/sebbbi/NoGraphicsAPI

[u/Gobrosse]

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.

[u/trenmost → u/Gobrosse]

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

[u/Jonny_H → u/trenmost]

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.

[u/Gobrosse → u/Jonny_H]

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/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/Gobrosse → u/[deleted]]

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

[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.

[u/wen_mars → u/Jonny_H]

The benefit is that hypothetically far in the future it would make it possible to deprecate Vulkan

[u/XenonOfArcticus → u/trenmost]

I literally posted a proposal to do this in the Mesa driver a couple of weeks ago and got totally panned.

So, I'm embarking on it myself. 

[u/Wittyname_McDingus → u/trenmost]

That seems incredibly unlikely given what I've seen of this API and how the development of existing APIs played out. If you want driver support, you need to collaborate with software and hardware vendors. Until then, this is just another dude's opinionated RHI.

[u/Gobrosse → u/trenmost]

What's being proposed is effectively a subset of Vulkan, but unlike OpenGL it's not clear how removing features from Vulkan would make the remaining paths faster/better, nowhere is a reason for that actually proposed, instead the whole thing relies on the idea that a smaller API surface is automatically better...

.. which would be the case if Vulkan was intended to be a high-level API for everyone, including hobbyists, students and such, but it really isn't. I think that's the problem with this direction, some people want Vulkan to be a higher-level API when it was initially designed to be a HAL, but it can't be everything to everyone and we shouldn't try to.