The maximum vertex buffer input bindings is set too low

[aloucks]

wgpu/wgpu-core/src/device/mod.rs

Line 37 in 77d95f5

pub const MAX_VERTEX_BUFFERS: usize = 8;

A super conservative value would be 16, but modern hardware supports 32 vertex input bindings.

https://vulkan.gpuinfo.org/displaydevicelimit.php?name=maxVertexInputBindings

The error I ran into manifested as a slice index out of bounds. I think this should really be a SmallVec or something similar that can handle more than the bare minimum.

wgpu/wgpu-core/src/command/render.rs

Line 971 in 77d95f5

for vbs in state.vertex.inputs[pipeline.vertex_strides.len()..].iter_mut() {

[kvark]

Thank you for filing!

A super conservative value would be 16, but modern hardware supports 32 vertex input bindings.

What use case do you have to need more than 4? :)

You are right that we need to support at least 16, according to Vulkan capabilities and our code in gfx-rs for other backends. Although, it's a bit more tricky than it seems on Metal: the vertex bindings are shared between descriptor resources and vertex attributes. And it can have up to 31 vertex buffer in total... So there must be a balance between how many vertex buffers we allow coming for the attributes, versus ones coming in a bind group. And I'd much prefer to have the higher limit for the latter, since I don't find multiple vertex buffers particularly useful.

The error I ran into manifested as a slice index out of bounds. I think this should really be a SmallVec or something similar that can handle more than the bare minimum.

Yes, I think SmallVec is a proper primitive in general for anything limit-related, since we know the baseline (minimum requirements), we can specify it as a fixed portion. In the near future, the limit on the vertex buffer count will be exposed in Limits, and you'll be able to request more than the standard amount.

[aloucks]

What use case do you have to need more than 4? :)

Loading glTF files using their buffers as-is without converting the vertex input.

The attributes aren't necessarily interleaved and the offset into the view sometimes exceeds the stride. It makes it difficult or impossible to put the attributes on a single buffer binding and you either need to (1) create an input binding per attribute or (2) pre-process the input into a custom/known vertex format. I'm trying to solve for (1) because (2) prevents you from loading the data directly.

Although most assets aren't going to have all of these attributes, once you run into models with animation, you can go past the limit of 8 pretty easily (which is what happened to me).

0. Position
1. Normal
2. Tangent
3. UV1
4. UV2
5. Color
6. Joint1
7. Weight1
8. Joint2
9. Weight2
10. MorphTarget0_Position
11. MorphTarget0_Normal
12. MorphTarget0_Tangent
13. MorphTarget1_Position
14. MorphTarget1_Normal
15. MorphTarget1_Tangent
16. MorphTarget2_Position **
17. MorphTarget2_Normal
18. MorphTarget2_Tangent
19. MorphTarget3_Position
20. MorphTarget3_Normal
21. MorphTarget3_Tangent

** I have a flag in the shader that disables morph targets 2 and 3 during compilation if only 16 input bindings are supported. This is why I opened gfx-rs/wgpu-rs#239.

[kvark]

I want to say that glTF is just not doing its best here - KhronosGroup/glTF#21
But I agree - that's the reality we have to deal with. In any case, even 16 isn't enough here, so we'd need to let you opt into more than standard count.