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 :)
Thanks @eventhelix :)
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
crabslabandcraballocand 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 :)
score 1 · canonical