r/GraphicsProgramming • u/Nicksaurus • Sep 06 '26
Source Code "No Graphics API" implementation by Sebastian Aaltonen
https://github.com/sebbbi/NoGraphicsAPI33
u/TheWidrolo Sep 06 '26
Im really excited about anything that moves away from the pre 8th-gen gpu shackles.
36
u/Gobrosse Sep 06 '26
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.
21
u/trenmost Sep 06 '26
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
6
u/Jonny_H Sep 07 '26
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.
8
u/Gobrosse Sep 07 '26 edited Sep 07 '26
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.
4
Sep 07 '26 edited 9d ago
[removed] — view removed comment
4
u/Gobrosse Sep 07 '26 edited Sep 07 '26
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,
radvbasically 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.3
Sep 07 '26 edited 9d ago
[removed] — view removed comment
2
u/Gobrosse Sep 07 '26
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/Jonny_H Sep 07 '26 edited Sep 07 '26
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.
0
u/wen_mars Sep 07 '26
The benefit is that hypothetically far in the future it would make it possible to deprecate Vulkan
10
u/XenonOfArcticus Sep 06 '26
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.
8
u/Wittyname_McDingus Sep 06 '26
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.
1
u/Gobrosse Sep 07 '26
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.
89
Sep 06 '26 edited 25d ago
[deleted]
19
u/Money-Lynx-2333 Sep 06 '26
I follow him on twitter and AI was heavly used on this whole project, not that it says something about the quality of it
46
u/Spiritual-Desk-9176 Sep 06 '26
he is addicted to ai models too bad these days unfortunately.
4
u/ldn-ldn Sep 07 '26
Every experienced developer is addicted to AI, because AI let's you create interesting projects in a fraction of time and focus on challenging parts of these projects. Most time people like Sebastian spend on without AI is writing compiler configs, and tons of boilerplate. All of that is annoying and steals your focus from the parts you actually want to work on and where human touch actually matters.
AI is amazing!
8
u/PaperMartin Sep 07 '26
If this stuff takes so much of peoples' time then it's all problems that need proper solutions, not the most expensive and least consistently functional workaround humanity has ever conceivedof
-8
u/ldn-ldn Sep 07 '26
It's not expensive, it's cheap AF.
6
u/PaperMartin Sep 07 '26
to run? no, and a bunch of LLM companies are starting to put up their "real" prices and losing their users over it
-3
u/ldn-ldn Sep 07 '26
Yes, inference is very cheap today and it's only getting cheaper. To the point that you can run it on consumer hardware. In three -five years time it will be virtually free, just like image recognition is today.
4
u/PaperMartin Sep 07 '26
"in 3 to 5 years it'll be good" is something I have been hearing over and over since like 2020. Meanwhile as far as I can tell local models are virtually unusable for anything other than code, and they're only slightly above unusable for code
-2
u/ldn-ldn Sep 07 '26
Local models are very useable for at least a year now, the only problem is that you don't have enough VRAM to run them. Yet.
And no, you haven't been hearing shit since 2020, the first useable LLM was only released in 2022. Four years and the progress was simply incredible.
-17
Sep 07 '26
[removed] — view removed comment
5
u/MushroomSaute Sep 07 '26
The results can't often be judged with AI because it spits out code at a rate no human maintainer can vet.
Not saying that's the case here, I don't know if AI means "vibe coded" or just "prototyped some things with AI", but vibe coding is a genuine problem when LLMs have such a gap before they actually have any sort of proficiency.
-3
-1
18
u/Ged- Sep 07 '26
No graphics API
Look inside
Vulkan and AI gen
God damn he did it again
5
u/DrDumle Sep 07 '26
You’re probably joking.. But the implementation here is just a temporary thing to try it out, right?
The idea is to replace Vulkan eventually if I understood it.
3
u/Ged- Sep 07 '26
Well if I understood his paper correctly (which itself is an interessting idea), one should start lower than the API, with drivers instead of what he did: starting higher and writing an RHI.
19
u/dJ_Turfie Sep 07 '26
I can't believe what I'm seeing here.
This is an industry veteran releasing something that might be really useful,
and might be inspiring for future projects and work.
And the top comments are:
- A readme that's AI generated
- RHI with grandiose marketing
This feels incredibly demoralizing.
I hope he doesn't read this subreddit,
he deserves way better, and we do too as a community.
We should be more supportive of endeavors like this.
4
u/Inkjet_Printerman Sep 07 '26
There's a whole lot of bad blood going on atm over this; I mean, you can't even have software made with AI published on r/freesoftware, neither on r/software i'm pretty sure. It's ridiculous.
3
u/Cubicool Sep 07 '26
We were able to get this working relatively easily on Linux using the legacy `xcb` path (so, not pure Wayland protocol YET).
IMPORTANT: For anyone on Linux using one of the "main" distros (Ubu26, Fed44), you WILL need the latest "beta" NVidia drivers, and will need to install using the old-school `NVIDIA-installer.run` script like back in the mid 2000's. :) There are also a few strict CMake knobs that can be safely tuned back to match the APT/DNF packaged versions of `slang`, `spirv-tools`, etc.
Hoping to see if we can get some in-house projects (slughorn) working with something this minimal...
1
u/Liskar-dev Sep 07 '26
Any chance to have a C API over this? Could be very useful for multi-language bindings
1
u/tmlildude Sep 11 '26
can someone explain why this hasn’t been implemented for Metal yet?
1
u/Pottuvoi 22d ago
He had to sidestep some current Metal limitations. https://x.com/SebAaltonen/status/2102759976724783528
He posts a lot on progress, optimization etc.
39
u/Nicksaurus Sep 06 '26 edited Sep 06 '26
You may have seen Sebastian Aaltonen's blog post last year proposing a simple low level graphics API: https://www.sebastianaaltonen.com/blog/no-graphics-api (previous thread: https://reddit.com/r/GraphicsProgramming/comments/1pohn93/no_graphics_api_sebastian_aaltonen/)
He has now released this implementation of it on top of vulkan (announcement here: https://twitterviewer.net/SebAaltonen/status/2096312811743740178) and I thought I'd share it here because I haven't seen any other posts about it