Remove inputSlot member from WebGPUVertexInputDescriptor

[litherum]

Part 1 of #146

[litherum]

We can enforce that they're parallel by making a new object which holds both items.

[kainino0x]

If we did this, it would probably make sense to use it in setIndexBuffer, copyBufferToBuffer and possibly BufferCopyView and BufferBinding too.

[kvark]

What's the reasoning for allowing holes in setVertexBuffers? It seems that it could be trivially replaced by multiple calls that don't have holes.

[magcius]

Have we figured out whether holes in setVertexBuffers unbind the buffer resource, or leave the old resource bound? If we leave the old resource bound, if I destroy the buffer, will the validation layer complain? How can I explicitly unbind the resource?

My recommendation, which is a bit bizarre, is that a hole/undefined means "leave existing resource", explicit null means "undefined", and we remove the startSlot parameter from setVertexBuffers, meaning that someone can use undefined for the same purpose. undefined is more flexible.

[kvark]

separating undefined and null seems like a recipe for troubles in WASM land

[kainino0x]

In principle I like being able to distinguish "keep" and "clear" but distinguishing null and undef/hole is just too unexpected IMO. In the meeting I think we decided for now that null/undef/hole would clear, and if you don't want to clear you just have to do multiple setVertexBuffers calls.

We could also disallow undef/hole and allow only null, if that would be less confusing.

[kainino0x]

Or I suppose we could do:

enum WebGPUSetVertexBuffersEntry { "unset", "keep" };
partial interface WebGPURenderPassEncoder {
    void setVertexBuffers(u32 startSlot,
        sequence<WebGPUBuffer | WebGPUSetVertexBuffersEntry> buffers,
        sequence<u32?> offsets);
};

[grovesNL]

Maybe in that case it would be better startSlot entirely and expect the full range to be passed? Otherwise we could accept ranges for keep/clear to reduce the amount repeated values.

[litherum]

This same logic should be applied to resource bind points as well, not just vertex arrays.

[litherum]

I noticed that GPUVertexAttributeDescriptor has u32 shaderLocation which is supposed to match what's in the shader source code, but GPUAttachmentDescriptor doesn't. It looks like fragment shaders would use MRT by referencing the index into the sequence<GPUAttachmentDescriptor> colorAttachments inside the GPUAttachmentsStateDescriptor.

[litherum]

This same logic should be applied to resource bind points as well, not just vertex arrays.

#188 does this.

[grorg]

Discussed in the 4 March 2019 meeting

[kainino0x]

I think this is obsoleted by #186 and #249.

Bind group/resource bindings and {buffer,offset} pair tbd.