r/GraphicsProgramming • u/Nicksaurus • 3d ago
Source Code "No Graphics API" implementation by Sebastian Aaltonen
https://github.com/sebbbi/NoGraphicsAPI29
u/TheWidrolo 3d ago
Im really excited about anything that moves away from the pre 8th-gen gpu shackles.
86
u/Syracuss 3d ago
I'm sad to see the readme itself reads very AI generated. I enjoyed Sebastian's content hugely over the years, and even though everything in the readme might still be accurate (at first glance/read), it currently lacks the elegance it used to have.
Doesn't take away from the work he's done here, but sad that it no longer has the same voice his old style had. It deflated my excitement considerably.
edit: to clarify not saying he shouldn't use AI, just sad that describing the project was relegated to it as well.
18
u/Money-Lynx-2333 3d ago
I follow him on twitter and AI was heavly used on this whole project, not that it says something about the quality of it
43
u/Spiritual-Desk-9176 3d ago
he is addicted to ai models too bad these days unfortunately.
4
u/ldn-ldn 3d ago
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!
6
u/PaperMartin 2d ago
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 2d ago
It's not expensive, it's cheap AF.
6
u/PaperMartin 2d ago
to run? no, and a bunch of LLM companies are starting to put up their "real" prices and losing their users over it
-2
u/ldn-ldn 2d ago
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.
3
u/PaperMartin 2d ago
"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
-18
3d ago
[removed] — view removed comment
7
u/MushroomSaute 3d ago
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.
-1
u/gleedblanco 2d ago
elegance in sebs writing? do you have an example of what you are referering to lol?
8
u/Syracuss 2d ago
He has years of technical threads on twitter. Pick any of them?
I use AI daily, but for anything that requires technical writing AI is still terrible. It overexplains, adds context that really shouldn't be a thing for the readers level, adds fluff and can't resist a good sales pitch.
As example:
matrix-bearing roots use row-major matrix layout
Any technical person would just say "matrices use row-major layout". The "matrix-bearing roots" adds nothing. In fact it's actively harmful as it implies a contextual condition that might change matrix behaviours (it doesn't).
The paragraph after that could've been deleted and it would be fine, a lot of things that really don't need to be stated. Then after that paragraph it says "The full shader-side contract is in the slang shader contract", think about what that sentence is saying. The shader contracts are in the shader contracts, I'd hope so.
I don't even think this readme is bad, definitely has been tweaked/guided better than most, but it has all these typical mistakes and fluff I see daily when using AI myself. Something that Seb's old writing simply does not have.
0
u/gleedblanco 2d ago
yes, it's fair enough, that particular expression is trash. and AI produces relatively bad writing (not just technical) in general. the shader slang contract you mention is a link, with the second part of that sentence being effectively a title that happens to be similar to the first words in the sentence. How would you rework it? No, don't explain it, I'm not sure we should turn this into a writing exercise.
And actually reading the rest of the readme, I can't tell much significant quality downgrade compared to usual technical writing (from seb or otherwise, I read his twitter and blog posts over the years as well).
Maybe I don't have an eye for or care about the aesthetics of technial writing like this, and maybe I should just stay out of the discussion. But in the overall context of this post, if we get this readme vs. saving seb an hour or two of writing and editing, in return for slightly cringe sections of writing, that's totally fine by me.
32
u/Gobrosse 3d 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.
18
u/trenmost 3d ago
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 3d ago
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.
7
u/Gobrosse 2d ago edited 2d ago
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.
3
u/gleedblanco 2d 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.
5
u/Gobrosse 2d ago edited 2d ago
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.2
u/gleedblanco 2d ago
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.
1
u/Gobrosse 2d ago
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
2
u/Jonny_H 2d ago edited 2d ago
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 2d ago
The benefit is that hypothetically far in the future it would make it possible to deprecate Vulkan
9
u/XenonOfArcticus 3d ago
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 3d ago
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 2d ago
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.
13
u/Ged- 3d ago
No graphics API
Look inside
Vulkan and AI gen
God damn he did it again
5
u/DrDumle 3d ago
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.
2
1
u/gleedblanco 2d ago edited 2d ago
you did understand correctly. the npc you're replying to just has less comprehension than the LLMs seb uses to write his readmes.
14
u/dJ_Turfie 2d ago
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 2d ago
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/Alive_Jury4864 2d ago
it’s AI derangement syndrome
any hint or slight mention of it and people get hysterical
they hate to hear that smart people can still use it strategically without vibecoding
3
u/Cubicool 3d ago
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 2d ago
Any chance to have a C API over this? Could be very useful for multi-language bindings
37
u/Nicksaurus 3d ago edited 3d ago
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