[coxmi]

Looking at the code examples (e.g. the cube[0]), I can’t get away from the idea that this looks very similar to standard OpenGL bindings, just with a different style of boilerplate.

At some point (for basic rendering examples at least), you’re always going to have to define a data layout of some sort, have that reproduced or reflected between the cpu/gpu environments, and iterate through each vertex. How exactly that turns into GLSL’s in/out variables feels to me like a relatively unimportant implementation detail that should be assessed on performance alone rather than usability[†]. I wonder if what we’re ultimately heading toward is better shader compilation, directly to SPIR-V, to support both bound and unbound use cases.

Sort of related, but Gabriel Dechichi’s engine [1] reflects shader vertex layouts back to C, so you get compile-time error handling if the struct layouts don’t match between cpu/shader.

[0] https://github.com/rkevingibson/loon_gpu/blob/main/examples/...

[1] https://m.youtube.com/watch?v=NTuLfB2ex5Q&ra=m

[†] Edit: Specifically talking about the final compilation unit here, not the shader language or library interface

[mschuetz]

> unimportant implementation detail that should be assessed on performance alone rather than usability

I disagree. Usability is important, or you end up with garbage like Vulkan. I'd rather have 99% of the performance for 100% usability, than 100% of the performance for 5% of the usability.

Unfortunately when it comes to graphics APIs, the choices are between bad and worse, which is why I switched to doing real time rendering in CUDA. Easier to write a fast software rasterizer in cuda, than to draw a single triangle in Vulkan

[coxmi]

Sorry, I wasn't clear (and have edited the post), I absolutely do believe that usability is important, and to be honest I feel like it's the main problem with graphics APIs (at least for my skill level).

Where I'm at now is that Vulkan is great because it's removed so many of the hard-coded assumptions that were previously hidden in the driver layer, allowing much greater CPU and GPU utilisation and performance when you need it (if you can get past the ugly APIs).

Where the usability stuff comes in is that it allows for the creation of alternative, higher-level shader-reflection setups that work brilliantly for simple use cases, all in user-space, which can open up shader programming for creative coders and a broader spectrum of developers. The lower-level APIs are then still accessible to those who absolutely need those performance levers.

[rkevingibson]

Generally I agree, but the bindless approach can give you both ergonomics and performance in some cases (not all). Certainly it can reduce CPU overhead - passing a single pointer to a shader is much faster than heavy bind group updates. The trade off is that you might have more pointer indirection on the GPU, which can introduce stalls.

Being able to use pointers and u64s for resources also makes having a shared header between shader and c++ source easier, though you still probably need some macro trickery to smooth over language differences. Metal is really good for this since the shading language is closest to C++.

[coxmi]

> but the bindless approach can give you both ergonomics and performance in some cases (not all). Certainly it can reduce CPU overhead - passing a single pointer to a shader is much faster than heavy bind group updates. The trade off is that you might have more pointer indirection on the GPU, which can introduce stalls.

Yeah I'm totally with you there, it just feels like the interfaces aren't that pleasant at the moment (although I've not tried Metal)

Edit: didn't realise you were the project author, I think it's great by the way!