Building Loon GPU: A Bindless Abstraction Layer for Modern Graphics
Writing a bindless GPU abstraction layer
Inspired by Sebastian Aaltonen's vision, I created Loon GPU to simplify modern graphics APIs by treating GPU memory as first-class pointers. This library eliminates complex buffer objects and bind groups, allowing developers to use vertex pulling and bindless textures directly. While currently supporting Vulkan and Metal backends, the project faces challenges with shader compilation in Slang, yet it significantly streamlines CPU-side code and offers a more natural programming model.
Having the API just give you pointers really does make the CPU-side code feel a lot more natural.
- chirsz
- sph
Someone has started to implement Aaltonen’s “No Graphics API” idea in Odin: https://github.com/leotmp/no_gfx_api
- 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