Naga has an experimental implementation of binding arrays, where you write globals like this:
@group(42) @binding(1729)
var a: binding_array<texture2d<f32>>;
and then there are new variants of (wgpu's analogues of) GPUBindGroupLayoutEntry and GPUBindGroupEntry that let you supply an array of textures as a's value.
Is it reasonable to ask WGSL to reserve binding_array on this basis? If so, then we have a graceful way to prevent people from using wgpu's binding arrays in WebGPU: they simply cannot write bind group layouts that permit them in the first place, so any shader that uses binding arrays cannot be used in any pipeline. (Naga does have feature bits, but we haven't generally used them for things that are part of the shader's interface anyway.)
Naga has an experimental implementation of binding arrays, where you write globals like this:
and then there are new variants of (
wgpu's analogues of)GPUBindGroupLayoutEntryandGPUBindGroupEntrythat let you supply an array of textures asa's value.Is it reasonable to ask WGSL to reserve
binding_arrayon this basis? If so, then we have a graceful way to prevent people from usingwgpu's binding arrays in WebGPU: they simply cannot write bind group layouts that permit them in the first place, so any shader that uses binding arrays cannot be used in any pipeline. (Naga does have feature bits, but we haven't generally used them for things that are part of the shader's interface anyway.)