Handle WGPUVertexStepMode_Undefined

[AlbinBernhardssonARM]

stepMode defaults to "vertex". https://www.w3.org/TR/webgpu/#dom-gpuvertexbufferlayout-stepmode

[cwfitzgerald]

I don't think is quite right actually - the behavior of undefined depends on the other arguments of the struct: https://github.com/webgpu-native/webgpu-headers/blob/main/webgpu.h#L4282-L4297

[almarklein]

@cwfitzgerald good to take that into account!

However, it's not clear to me how these different cases of "no attributes" should be mapped to the API in wgpu-core. And it looks like null is not allowed in the JS API?

[AlbinBernhardssonARM]

@cwfitzgerald good to take that into account!

However, it's not clear to me how these different cases of "no attributes" should be mapped to the API in wgpu-core. And it looks like null is not allowed in the JS API?

null is allowed in GPUVertexState.buffers. However, Firefox doesn't appear to handle this quite correctly. null entries are supposed to be skipped during vertex processing and validating draw calls. But the following fails in Firefox (works in Chrome) due to no vertex buffer being bound in slot 1:

let pipeline = device.createRenderPipeline({
  vertex: {
    buffers: [
      {
        // Vertex buffer slot 0...
      },
      null
    ],
    ...
  }
  ...
});

...

renderPassEncoder.setPipeline(pipeline);
renderPassEncoder.setVertexBuffer(0, vertexBuffer);
renderPassEncoder.draw();

Can be worked around by binding some dummy vertex buffer to slot 1.

The reason is wgpu-core doesn't handle null entries in VertexState.buffers. Firefox handles it by simply putting default values on null entries. However a null entry is not quite the same as an entry with attributes = []. An entry with attributes = [] still has to have a bound vertex buffer, based on the outcome of gpuweb/gpuweb#4999 .

So I think the proper, long-term solution is to handle null entries in wgpu-core. Short term solution for wgpu-native is either

1. Match Firefox behavior and map WGPUVertexStepMode_Undefined, empty attributes or WGPUVertexStepMode_VertexBufferNotUsed as default values { array_stride: 0, step_mode: Vertex, attributes: []}.
2. Raise an error. Which we already do since we don't handle WGPUVertexStepMode_Undefined or WGPUVertexStepMode_VertexBufferNotUsed. But we could handle WGPUVertexStepMode_Undefined for the non-empty attributes case. And i.m.o. current error message is not too helpful as it implies the wrong vertex step mode was used, when in fact the user did nothing wrong.

I've updated my commit to do 2 with an error message telling developers how they can work around the lack of support, but I can change it to 1 if we prefer.

Note: WGPUVertexStepMode_VertexBufferNotUsed will be removed next time we update webgpu-headers.

[cwfitzgerald]

Sorry this got lost in the sea of PRs - could you take a look at the current state of wgpu-core as I think some of this may have changed? I'm going to try to get a wgpu update up for wgpu-native at some point soon.

[AlbinBernhardssonARM]

wgpu-core (trunk) looks the same to me. VertexState.buffers still takes [VertexBufferLayout] (not [Option<VertexBufferLayout>]) and VertexBufferLayout.step_mode is VertexStepMode which doesn't have an unused entry. So still no way to express an unused slot as far as I can tell. Constrast with eg. FragmentState.targets.

The example JS I gave still doesn't work in Firefox. (A dummy vertex buffer has to be bound to make it work.)

[cwfitzgerald]

Thanks!