I’ve been working on a game engine for a while, based on Vulkan and using GLSL compute shaders extensively.
I’ve been puzzled about two seemingly very simple features that I’m constantly missing in the code I’m writing:
Auto-incremented enum style constants. I’m doing a lot of comparing against lists of IDs or types that I would naturally implement as enums in C, and that I’d like to match with the values of my C-side enums that are being passed by value from C to the compute shaders and back.
I’m working around this by creating constant integers with the values manually written in, but it is quite error prone and would seem like both a very common use case and simple to implement.
I’ll probably add some simple C-side glsl pre-processing of my own to improve my workflow, but it seems like it would be a generally useful feature.
A sizeof operator would be tremendously useful in debugging alignment and padding issues. Ideally with an accompanying offsetof operator. Getting data in a uniform or buffer struct to line up properly from C to GLSL so its contents are equally usable on both ends is a recurring pain and I’m having to do a lot of blind trial and error. My structs have many members of various sizes, so I often mess up my padding on the corresponding C side, though I’m getting better at learning the rules (and using more and more vec4s even when not strictly needed…).
Being able to return the struct size or member alignment seems like it would help a lot to cut through to the answer, rather than my current method of writing a debug value into a struct member from the compute shader and checking where it landed on the C side. I don’t see why this wouldn’t be trivial to implement.
What I might do to help with this is parse the disassembled SPIR-V for clues on how struct member offsets differ from my matching C-side structs. But again, this seems so basic that I don’t understand why it isn’t already available.
I haven’t seen much or any discussion around these two features - how does everyone manage to pass properly structured data to their compute shaders and back? Am I just using compute for more than it is intended for? I must say, apart from those two details that I’m manually working around, things have been working pretty great, so I don’t see why not to use compute shaders in this way.
Curious to hear everyone’s thoughts and if you think these should be features in the language or not.