I don't know that DynamicStorageBuffer really makes sense tbh, I've thought that we should remove it. Typically you don't need dynamic offsets if you're binding a storage buffer anyways.

Ok I didn't realize the "dynamic" was for the dynamic bind offset. From there I'm guessing that this buffer was added for the same (niche) reason I added mine in Hanabi, which is to be able to bind both the entire buffer but also individual elements. If that's the case this should be documented because this implies all elements are individually aligned, which has the potential for a lot of wasted padding, so should be carefully considered.

(individual elements or any other subset view if the array, the binding doesn't need to be a single element in size, what's important is the start of the bound view)

Ping @JMS55 before this gets into limbo, can you please clarify? I'm not asking about whether it makes sense or not, just that we at least document what this is (and at the very least on this issue, so someone can pick up the work to write the doc PR). Thanks!

Yes, DynamicStorageBuffer is just a StorageBuffer, but also allows you to set dynamic offsets. Tbh I don't actually know how dynamic offsets work with storage buffers (what's the point even? You have the whole buffer bound at once anyways, no need to slice it up per binding...). I've never used it.

The point is say you have a buffer that stores an array of struct. This is especially common if you batch several items. In one compute pass you bind it as a whole and work on the entire array. But in other passes you bind just one element, or a chunk (= view = sub-array) of it. In Hanabi this is "work on all particles" vs. "work on a single group" (which is stored alongside all the other groups for the effect, inside the same buffer). Why is that helpful compared to binding the whole buffer? Because your compute pass doesn't need to know how to address the chunk; it's implicit by the binding, so saves on extra data to pass. Now, I believe the key aspect here is not about the usage of dynamic offsets, but the fact that if you want to bind a sub-array, then the first element of that sub-array needs to be aligned according to min_storage_buffer_offset_alignment (independently of whether the offset in the storage buffer was specified at layout time or dynamically at bind time), which can be up to 256 bytes on some platforms (macOS silicon in particular). And that means all elements of the array need to be aligned like this, unless you know exactly where the chunks you bind are in advance. And aligning all array elements to e.g. 256 bytes takes a lot more wasted padding than only aligning the start of the array. But sometimes it's still worth it (better have 30 elements and waste 500 bytes, but run only one compute pass, than having to handle 30 separate tiny buffers and dispatch 30 separate compute passes to avoid the padding).

Is DynamicStorageBuffer for this usage? That's what I'm trying to confirm.

Sounds right to me, but idk for sure.

Ok thanks, I'll dig into the code if I have time, or if someone else knows...

Ok that's actually just a wrapper around encase's own DynamicStorageBuffer, which clearly points at the default 256 bytes and the others per-device limit >= 32 bytes mentioned above.