📦 Bundle size

Full ESM build, minified and gzipped.

🌳 Bundle size after tree-shaking

Minimal build including a renderer, camera, empty scene, and dependencies.

By curiosity, by how much does it improve the performance on your test ?

@Makio64 So far, it's more expensive than typical drawIndexed on Chrome macOS since it does almost the same with the overhead of an indirect buffer updated every frame, but the idea is that we handle all this in compute shading, which is where performance should improve.

If you reserve the same number of vertices for each geometry, drawIndirect/drawIdexedIndirect works very well, then it's all a single drawCall, because you can assign all objects to the indirectBuffer with atomic add. The disadvantage is that if you have objects with very different vertex counts, you use unnecessary memory because you have to reserve the highest vertex count for all objects. But if, as with an instancedGeometry, all instances have the same vertex count, it's perfect.
I didn't know that WebGPU now also has multiDrawIndirect. I'll have to check that out.

In your case, where you have a dozen different primitives, this would also be very easy to do with drawIndirect/drawIndexedIndirect, since each instance of a primitive has the same vertex count. Then, with 12 different primitives, there would only be 12 drawIndirect drawCalls and you can easily push it up to the buffer limit without causing frame drops.

I'm currently converting my terrain generator to drawIndexedIndirect. I'm almost finished with it now. The entire terrain is a single draw call. Frustum and occlusion also does everything the GPU with a compute shader.
If you continue to follow the topic of multiDrawIndirect, I'm happy, because I am far more of a user and have only limited time to be a contributor.

@RenaudRohlinger Does atomic.add work for you with metal now?
I remember there were problems there.