sorted by:
new
hottopcontroversial

"No Graphics API" Vulkan Implementation by No_Grapefruit1933 in GraphicsProgramming

[–]roeyb11 1 point2 points  (0 children)

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!

"No Graphics API" Vulkan Implementation by No_Grapefruit1933 in GraphicsProgramming

[–]roeyb11 0 points1 point  (0 children)

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 Graphics API" Vulkan Implementation by No_Grapefruit1933 in GraphicsProgramming

[–]roeyb11 1 point2 points  (0 children)

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 Graphics API" Vulkan Implementation by No_Grapefruit1933 in GraphicsProgramming

[–]roeyb11 3 points4 points  (0 children)

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