Rust to WGSL transpiler `wgsl-rs` released

19 points by schell

eventhelix

Nice milestone. Sizing buffers per WGSL §14.4.1 instead of size_of seems like exactly the kind of Rust/WGSL mismatch that's easy to get wrong.

Question about the ECS that runs on the GPU: are you planning to store components as struct-of-arrays (e.g., one storage buffer per component type), or keep everything in a single crabslab-style slab with array-of-structs records? I'm curious how wgsl-rs would handle each case, e.g., whether SoA means many bindings per shader, and whether the WGSL layout rules stay transparent when a component is a runtime-sized array.

schell

Thanks @eventhelix :)

are you planning to store components as struct-of-arrays (e.g., one storage buffer per component type)

I'm planning on doing some experimentation. When I wrote my last ECS crate apecs, which runs on the CPU, I started with a struct-of-arrays storage and then transitioned to archetypal which really made iteration much faster at the cost of slowing down insertion/removal. With having to synchronize between the CPU and GPU I think the insertion/removal cost will be amplified, so I don't think there's much merit in storing components that way on the GPU.

The strategy is still murky, though I have a POC I wrote last year using Rust-GPU. It's based off of crabslab and craballoc and maintains three storage buffers - entities, components and events. An entity is a type-erased bag of pointers into the components slab. Components are raw data, and must be plain-old-data. This means they can't be things like runtime-sized arrays, unfortunately, as those carry a bunch of extra requirements (each one must have its own binding). There are also some hard limits with WebGPU regarding the number of storage buffers per shader stage which is, generally, I think, 8. So it makes more sense to support using runtime-sized arrays in your systems as "resources" instead of components.

But that's just like, my opinion, man ;) (Lebowski quote).

As for the WGSL layout rules - I think those are going to go out the window for component storage, as the components will be packed as tightly as possible according to the slab read and write rules set by crabslab.

I think all of this is a really fun problem to work on, and if you're interested feel free to reach out on github on any of the repos in the future :)