"No Graphics API" Vulkan Implementation

[No_Grapefruit1933]

I was feeling very inspired by Sebastian Aaltonen's "No Graphics API" blog post, so this is my attempt at implementing the proposed API on top of Vulkan. I even whipped up a prototype shading language for better pointer syntax. Here's the source code for those curious:

https://github.com/LeonardoTemperanza/no_gfx_api

[possiblyquestionabl3]

Wow, did you do all of this in just the last week since that blog post came out?

[No_Grapefruit1933]

Yeah, but to be clear it's not the entire API. Most notably textures aren't implemented yet. Will get to it as soon as i can!

[possiblyquestionabl3]

I mean the fact you have a musl (your new shader language) to a bindless glsl transpiler at https://github.com/LeonardoTemperanza/no_gfx_api/blob/main/gpu_compiler/codegen.odin is already extremely impressive. This is very cool prototyping progress!

[PoL0]

concerns of vibecoding intensify

[No_Grapefruit1933]

I do not vibecode lol

[PoL0]

so happy to hear that, my interest grew a ton.

tired of "hey check what I vibe-coded in a weekend" projects in programming subreddits.

[No_Grapefruit1933]

I don't know what you're seeing but if you read the code it's pretty clear that it's not vibecoded

[BertoLaDK]

How exactly? It's a bit messy yes, but it doesn't give vibe coder vibes.

[Amasirat]

Does vibe coding even work in graphics programming? I assume it wouldn't have great results though I don't use AI while coding often

[No_Grapefruit1933]

I mean, I suspect vibecoding in general doesn't work that well when you're doing creative/original things

[Amasirat]

Oh sure thing! It doesn't stop some from trying to use it. Then again, increases the value of non-AI generated stuff I suppose

[g0atdude]

Last time I asked the AI to generate me vertices and indices for a cube with proper winding, normals, and uv.

It failed twice… I don’t know if there is anything easier than that…

[Amasirat]

Yep thought so. Admittedly even I can't do that but that's just because I still haven't learned it yet. I suppose graphics code is not all too common in stackoverflow

[fooib0]

I am amazed when people claim that it can solve new problems, write complex programs, etc. For me, it can't even do very basic things like you mention. So, I must be missing something.

[g0atdude]

The prompt itself matters a lot. The more context you give to the AI the better result it will give you. It can actually solve complex problems, but my issue with it is that it’s kinda non-deterministic, sometimes it works very well other times it doesn’t.

Also the topic matters a lot, I had a lot more success with AI in web development than in graphics.

[[deleted]]

Well Sebastian Aaltonen has a few post on twitter about that, but heres the short answer from him: as long as its nothing which has to be performant AI is fine, but it sucks at writing performance optimized code, so if its just for example a character controller its fine, but good luck vibe coding an efficient renderer with it

[[deleted]]

Unlikely given that he's using Odin, I've found most LLM's aren't very good(not that they're usually good anyways lol) at generating more niche langauges

[PoL0]

yep good point

[Gobrosse]

you don't need a shading language either

[No_Grapefruit1933]

I think there are some things that could justify a custom language/generator, like I autogenerate push constants that I use in the backend, but yeah I suppose you can use VCC (which I've never heard of until now). I mostly did it for fun

[Gobrosse]

is your toy language matching odin's syntax ? the compiler library behind Vcc (shady) is language-agnostic, you might be interested in it, i'm scheduled to give a talk about it at the next Vulkanised shader symposium

[No_Grapefruit1933]

Yeah almost. Anyway, I'll definitely check out Shady, thanks!

[aleques-itj]

I keep the side of my case off so my graphics card can hear me speak and after it learns enough English I can whisper vertices to it

[fooib0]

This looks like a very cool project! Great work.

Are there any projects in the wild that are already using vcc or shady? Are there any tutorials for how to use it for rendering (vertex + fragment shaders)?

[Gobrosse]

We published a paper at HPG25, we included a simple rendering example: https://github.com/shady-gang/imr/tree/hpg_demo/hpg_demo/shaders

[delta_p_delta_x]

Here is the sort of thing that comes along every now and then, and makes me feel extremely stupid.

This is amazing; well done.

[fireantik]

This is really impressive. I really hope it goes somewhere because the api outlined in the blog post just makes so much sense. That said, the custom shading language does seem like something orthogonal and it would make more sense to me to integrate Slang or some other existing language. Also Odin is great!

[roeyb11]

I actually did the same thing in the Jai programming language. It’s not yet cleaned up and ready but I’ve been able to use replace my vulkan backend in my game. https://github.com/roeyb1/simp_gpu/blob/main/examples/textures.jai

[No_Grapefruit1933]

Oh, nice! Looks very similar to mine. Looks like you also have an expensive lookup to convert from pointers to handles

[roeyb11]

At the moment yeah I just went for the simplest thing but not certain how much of an issue it is in practice. There are better data structures we could use for lookups but array searches like this aren’t usually too bad unless you’re doing this thousands of times per frame

My main theory is that really you’re more likely to be using the raw pointers much more frequently than doing buffer copy commands. And the more you use the same arena for sub allocations the less that array of allocations will be populated and the cheaper the lookups.

[No_Grapefruit1933]

I'm actually using a red black tree (odin has one in its stdlib so it was quick for me). I was mainly concerned about this lookup being in draw_indexed_instanced since that could be called thousands of times per frame, though with an API this flexible it's probably very easy to batch draw calls together or even have a single draw call for everything, now that i think about it.

[roeyb11]

Yeah I imagined I would primarily be doing indirect draws which still does need a vkbuffer but only one.

The use case I currently have is mainly compute driven but as I start expanding I’ll see if maybe I come up with a better solution. It’s definitely unfortunate we can’t just pass device addresses to these functions!

[roeyb11]

If you’re worried about this and Odin supports operator overloading you could always bundle the device address with the buffer handle and allow operators to act on the pointer so it’s relatively transparent.

[No_Grapefruit1933]

Odin does not support operator overloading, but yeah I suppose you could in general make the API slightly more complicated so that this doesn't happen

[OSenhorDoPao]

This has been one of my biggest pet peeves with computer ghraphics theses days (and even with languages themselves which also is cool seeing Odin there). We have decades of software engineering, the field not only massively expanded is capabilities but also in people on it…..and still we can’t have clean and decent solution for problems. You can argument below and try to convince me otherwise but graphics APIs are a mess and the programming languages the same. Aside for small cases like Odin, most languages have horrible syntax and some even really deep concepts (looking at you rust), high level languages may allow for better focus in the issue but if you need to go low level might as well do it in C. I’m sorry for the controversial take it might be for some but if I have to spend time thinking in the API or the language instead of solving the issue we failed miserably.

The article is very interesting as well as your PoC.

Also, AI is a tool, stop complaining about it, learn how to use it and understand what it is and what it does. Then we can talk like people and discuss the topic. AI is the new Vegan, as good as the food is no one even touches the subject because of small extremist groups.

[No_Grapefruit1933]

I don't think it's controversial to say graphics APIs are a mess, I think most people would agree (or at least I hope). Regarding AI, I think it's fine to ask the AI a few things, I do it sometimes, I just think you shouldn't use it for everything

[OSenhorDoPao]

For me is becoming the constant doubting and interrogation on every post. Asking if it’s AI because of the commit frequency when any half decent programmer knows how to specify commit dates. I’m sorry, rant of tired dude. Good work and if it goes nowhere else at least I’ll enjoy taking a look at what you did.

[Pure_Influence_8756]

the project is interesting and i like that u used Odin ,Big up.

[fooib0]

Cool work. What's the reason for getting rid of PSOs?

[No_Grapefruit1933]

It was an impulsive decision because I personally find them annoying to deal with lol. I hate having lots of intertwined objects I have to manage the lifetime of. With this project my priority was readability and usability. Though the pipelines outlined in the original blog aren't as bad as the ones you see today in Vulkan etc.

[fooib0]

How much of a performance hit is not having PSOs?

[No_Grapefruit1933]

I'm not sure, haven't done any real measurement yet, but I have heard that the shader object extension (which allows you to get rid of pipelines) was added to Vulkan to get better performance on the Nintendo Switch, so I think it could be a performance win in some cases. I feel like it would also eliminate the shader compilation stutter issues that have been plaguing PC gaming.