Use uint here. This is what GL expect.

I think you need a barrier here to wait for compute to finish before reading. We already have GPU_memory_barrier for that.

Maybe the sync is implicit due to GPU_texture_read but I don't know how it will work for vulkan. Moreover, it does not hurt since it's just a test.

Yes I removed the barrier as I couldn't detect any difference. No problem to add it back.

add if (lib)

I would prefer the vertex and index buffers to be treated as other resources (texture, ubos) in that regard. Meaning you should only expose getting the binding location from the shader and have a dedicated GPU_vertbuf_bind_as_ssbo(GPUVertBuf* verts, int binding) method (similar for ibos too).

Commit this change in master directly.

Instead of exposing this, could we only support U32 for device only buffers? This way readback would always produce uint32_t data.

I'm not 100% sold on the device only name. If you can read it back, it is not device only. Maybe GPU_indexbuf_create_empty or GPU_indexbuf_create_noinit and make it return the GPUIndexBuf pointer.

Also from the parameters, I expect this goes below void GPU_indexbuf_init(GPUIndexBufBuilder *, GPUPrimType, uint prim_len, uint vertex_len); at L.60.

Maybe another better option is to have it named like this:

GPUIndexBuf *GPU_indexbuf_build_on_device(GPUPrimType, uint prim_len);

With a getter to get the type of indices.
This has the benefits of isolating the selection of GPUIndexBufType inside the GPU module. This way we can easily override the type if we need to.

use uint for all bitwise operations. Also the indices are uints too.

the mask index2 & 0xFFFF is redundant.

I would wrap this inside a GPU_indexbuf_read which should be similar to GPU_texture_read.
Meaning it would return a buffer (with its ownership) and eventually convert the data if data format mismatches.

Copy/Paste failure? Not sure what texture is for here.

uint

I don't have objections to support U32 only. It makes code more clear, but would loose some performance when drawing meshes up to 64k-1 verts.

I would go for build_on_device.

In the current structure of the draw manager we want to allocate it before we initialize it. The compile unit that allocates is different than the module who initializes it (draw_cache_impl_mesh vs draw_cache_extract_mesh). We might want to add an init function later when we want to use it in use it in draw_cache_impl_mesh. Emphasis on "might" as it isn't clear if that will be needed.

Remove comments

code format

We should not call indices per primitive, the number of elements should be a parameter. Not all primitives has a constant for this.