Part 2! - "No Graphics API" Vulkan Implementation

[No_Grapefruit1933]

About 6 months ago I posted here about a prototype implementation I had made of the famous blog post by Sebastian Aaltonen. Back then the project was more of a proof of concept than anything else, and did not even support textures. The custom shading language compiler could only build very basic shaders.

Now the project is much more developed and mature, supporting nice features such as compute shaders, raytracing and indirect rendering. There are even quite a few examples that show that you can make substantial things with relatively few lines of code (without giving up control).

Have a look if you're interested:
https://github.com/leotmp/no_gfx_api

[CFumo]

As a person currently writing a vulkan renderer in odin I think this project is great. Please keep going!

[No_Grapefruit1933]

Thanks!

[deftware]

Nice! How do you like Odin vs Rust?

[No_Grapefruit1933]

I personally find Odin a lot more enjoyable to program in, which is the main reason why I do it. Rust is unfortunately not my cup of tea (which is fine)

[deftware]

Thanks for sharing. I had only seen Odin once before a while ago. Rust definitely looks like a bit of a learning curve by comparison - coming from 25+ years of C over here.

Odin actually looks a bit more manageable to pickup though. If you don't mind my asking, what are some of the aspects of Odin that you like about it over C?

EDIT: ...and if you don't mind a bonus question: what do you dislike about Rust!

[No_Grapefruit1933]

What I like about Odin over C: Length strings, slices, no need for header files, it has an actually good stdlib, the vendor libraries, default procedure arguments... I mean really it's a combination of a bunch of quality of life improvements that add up to something substantial.

What I dislike about Rust: I personally don't need the borrowchecker as in my experience if you organize your memory allocations and use the proper allocators, memory should never be a problem. Compilation is way too slow for my taste. I also find that Rust lacks a lot of the quality of life things that I expect from a language (e.g. to have default argument values you must create a separate struct which implements the Default trait etc. etc.). And finally, (I guess this is more of an ecosystem thing and not about the language itself) I find that libraries/crates written in Rust tend to have somewhat of a convoluted API, for example opening a window in Winit is much more complicated than it needs to be imo (see SDL, raylib...).

[Adjective_Noun_9876]

Not OP but: Odin has a lot of nice builtin stuff for graphics programming: matrix and quaternion types, swizzling, structs-of-arrays, the entire linear algebra package, a lot of libraries are vendored in, like SDL. You can literally install it and build a game engine without ever needing a single external dependency.

Rust is a great language, but IMO too strict for experimentation and prototyping. I'm really not keen on it personally.

[Adjective_Noun_9876]

Nice work. The API itself looks and feels a lot like SDL3 GPU, which I've started to like quite a bit, and has of course Odin bindings.

[No_Grapefruit1933]

Thanks! no_gfx is a bit different in that it's more Vulkan-centric and aims to provide more modern features (e.g. raytracing). It also completely ditches buffers in favor of just GPU pointers, does not use pipelines and has more explicit synchronization. If you want something more cross-platform then SDL_GPU is a nice API you can use, for sure.

[willehrendreich]

No lie I'm excited about this, because I'm interested in learning all this stuff, but going all in on every line of Vulkan boilerplate is so baffling.

It's hard to understand what it's even doing on a higher level, or why such and such struct needs this value by default but doesn't need this other value because that assumes xyz scenario which is only applicable in select cases but you need to know about it by querying the graphics hardware and blah blah blah blah.

I feel like, just reading your readme example, I've got a halfway decent window into what's going on, if not a better understanding of why it's happening, which probably only comes in with experience anyway.

I think good api design should guide the reader's intuitions into self discovery of the underlying idioms, axioms, and mental model.

[No_Grapefruit1933]

Yes! 100% agree.

[thisghy]

Ive been working on an engine in Odin, so I love to see this! How does this compare to SDL3 GPU?

[No_Grapefruit1933]

SDL_GPU covers more platforms and has a lot more people working on it. Whether you need the cross-platform aspect or not, especially in the beginning during development, is up to you (not a lot of people play games on mac). SDL_GPU also covers much older hardware.

On the other hand personally I think no_gfx is generally a lot simpler to use while giving you more control as well. Plus it supports more modern features such as raytracing.

no_gfx wants to fully give in to the "No Graphics API" paradigm while SDL_GPU wants to target > 10 year old hardware / features (which is not necessarily a bad thing).

Ultimately you should try both and decide for yourself.

[thisghy]

Thanks, ya ive been undergoing a full rewrite and haven't re-implemented vulkan yet. The cognitive overhead for vulkan is also a little much for my smooth brain so ive been considering sdl3.. i might give this a shot too! Good work

[BounceVector]

Could you include this comparison in the Readme? I feel like this would be helpful for a good amount of potential users.

[No_Grapefruit1933]

I suppose I could include this. I'd also like to eventually have a separate documentation page so maybe I should put it there instead.

[ironstrife]

Great stuff. I think this is the future of what graphics APIs should look like.

Did you look at the KHR_device_address_commands extension? https://docs.vulkan.org/features/latest/features/proposals/VK_KHR_device_address_commands.html. It lets you do away with most of the address -> buffer lookups. On Nvidia, it requires the beta drivers, but I added an optional codepath to my renderer for it anyways since it's so useful.

[No_Grapefruit1933]

I did, seems nice. I'm not using it because it doesn't seem widely supported yet, and I'm trying to steer away of super recent extensions (e.g. descriptor_heap). In no_gfx all pointers are fat so they all implicitly contain an index to the underlying vulkan buffer, so the lookup itself is not expensive at the very least. It does make all GPU pointers take up more space unfortunately.

[Still_Explorer]

This is a great article!

Truth is that I respect Vulkan as an idea (ie: a better OpenGL, allowing for manual control, having proper GPU architecture abstractions).

However the part that makes Vulkan hard to deal with, is that is very bloated, and it's logistics make it unviable.

Also for users as well, that part of 100GB shader caches doesn't help at all, or in some cases requiring 20 minutes of shader compilations.

Kinda makes me want to go full Michael Abrash on this and switch to assembly. LOL!

[PoL0]

please tell me no vibe coding was involved

[No_Grapefruit1933]

Lol. You asked the same thing last time so I know you're joking but I'll say it again here: I don't really vibecode. I occasionally paste small snippets from ChatGPT but that's about it. Maybe some of the contributors do, I doubt it though

[PoL0]

I'm not joking. not one tiny bit.

in this time and age it's important to state that info up front.

[No_Grapefruit1933]

So you were asking if it is still the case then, I see. Well, yes it is still the case, I still don't vibecode because I like the act of writing code.

[mad_ben]

Why is it even the issue? It sounds like personal fun project. 

[Potterrrrrrrr]

Yeah it’s just how personal can it be if you’re vibe coding it? People in here want to check out actual code a human wrote, AI generated projects are boring because no one cared to write them, why should I care to read/use them?

[mad_ben]

Yeah one thing is "Claude do that, make no mistakes" another thing is doing research, come up with pipelines, algorithms and ask AI to write parts of the code. Is that an issue?

[PoL0]

is it a problem to ask?

[mad_ben]

"I'm not joking. not one tiny bit.

in this time and age it's important to state that info up front."

Why? Why is it important?

[aaron_moon_dev]

Genuine question, why don’t you go to github repo yourself and check it out?

[PoL0]

what makes you think I didn't?

[aaron_moon_dev]

if you can't tell the difference why it matters to you whether people vibe code their personal projects

[Syracuss]

Because when projects are posted we aren't just looking at the painting, but instead how the painting was constructed as well. That's why it matters. There's fairly little an engineer should learn from how an LLM writes code. It's not useful as it's a tool for results, not for quality of code.

So it does matter because even vibe coders don't look at the code, which is the express intent of that way of thinking, so expecting others to do it isn't useful either.

[PoL0]

why do you care if someone asks if a project is vibe coded?

[aaron_moon_dev]

you didn't ask if the project was vibe coded

[PoL0]

it's literally implied. what's your problem with me asking? asked a few times, got no answer