Perhaps we could find a better single-word alternative to "readonly-storage"? For example, "read-buffer" and possibly the corresponding "read-texture" instead of "sampled-texture".

This is the same problem as discussed in #256: uniform buffers are read-only but use a different HW path compared to readonly storage buffers.

I'm not suggesting to unify "uniform" and "read-storage" usages, here I'm only talking about the name for the latter.

So uniform-buffer and read-buffer? It seems more confusing imho because it isn't clear for experienced GPU developers what the difference is between the two. Maybe read-storage-buffer?

I just feel like "read-storage-buffer" is both unnecessary long and inconsistent with the texture one ("sampled-texture"). Experienced GPU developers are likely to recognize "uniform" and be able to distinguish it from other usages.

I think it would make sense to move the "dynamic" flag as another boolean field near the GPUBindingType instead of combinatorically exploding the binding types (think about what happens if/when we add texel buffer views...)

Done.

The title of the change does not mention anything about this flag. What does 'dynamic' mean in this context? Please add comments in the IDL or a section in the document that explains.

Done. This was changed to address @kvark's concern that we have a combinatorial explosion of binding types.

Thank you for the clarification, @Kangz . Why does the implementation need to know whether a binding is dynamic or not? Will it be a validation error if you set "dynamic = false" and use a dynamic offset anyways?

Implementation needs to know if it expects that extra offset at the binding time. For example, in Vulkan it would use a different VkDescriptorType. The validation would need to make sure that exactly as many offsets are provided as there are dynamic buffers in the bind group.