Claimed buffer limits are not supported on Metal

[andyleiserson]

wgpu-hal's Metal backend sets its internal limits to max_buffers_per_stage to 31 and max_vertex_buffers to crate::MAX_VERTEX_BUFFERS, which is 16. It then sets the WebGPU limits max_storage_buffers_per_shader_stage and max_uniform_buffers_per_shader_stage to equal max_buffers_per_stage.

The vertex pulling transform creates VertexBufferMappings with IDs calculated from vertex buffer indices i as max_vertex_buffers - 1 - i. Unfortunately it's been some time since I noticed this bug so I'm fuzzy on the details, but I believe that approaching the maximum number of vertex buffers can result in a conflict with other assignments to the low buffer indices.

I believe that max_buffers_per_stage of 31 reflects the capability of current hardware. WebGPU does not provide a way to specify the pooled limits, so to be compliant, we need to decide on some fixed allocation of the 31 hardware buffers to storage buffers, uniform buffers, and vertex buffers. Alternatively, JimB mentioned that it may be possible to nest some of these resources within argument buffers.

[Vecvec]

I don't think this is going to change any decisions, but (unlike on other APIs) Metal also counts acceleration structures as buffers which (when they are added in #8071) might also need some room. At least for now, this doesn't matter - probably not until it gets taken out of experimental which will be a long time (I'm not sure how many people need more than 1 TLAS anyways) - but it's probably worth noting.

[jimblandy]

Switching to represent bind groups with argument buffers is a major change that loses some compat.

[andyleiserson]

Some related discussion on Matrix: https://matrix.to/#/!MFogdGJfnZLrDmgkBN%3Amatrix.org/%24jFH7-iSaC_FVpbGAtMh4Rj6hMwA3lzMCMBEe4S_vwUU