Thread by @SebAaltonen

Managed to generate binding ids for the generated GLSL shader for GLES3/WebGL2 using SPIRV-Cross API.

GLES doesn't have sets, so I must generate a flat contiguous range of binding ids per set and store the set start index. Runtime binds N slots at a time (bind groups).

I also must dump a mapping table for combined samplers in the shader. Our renderer has separate samplers and images.

Our textures and bind groups are both immutable. So I can just store 2x GLint per combined sampler. This is 64 bits per combined sampler. Easy to offset allocate them all in a big buffer. Bind group has start offset and count.

GLES doesn't have generic buffer bindings like modern APIs. Have to bind different types of buffers separately. That's a bit annoying. We need to have a bit of metadata also in the buffer bindings to be able to bind them correctly.

I am confident I can store bind group bindings in a tight space and write optimal binding code. But it's not going to be as fast as Vulkan and Metal, since GLES requires separate binding call per resource.

But it should be faster than traditional renderers requiring multiple software command buffer calls. We just write one uint32 to our software command buffer when we bind a group, even in GLES. And the group likely fits in one cache line. It's basically 100% GLES driver overhead.

NOTE: In the original image, there's the same binding index for the UBO and the first texture. This is intentional. GLES binding indices are type specific. Vulkan and Metal instead have shared binding slots for all resources.