See also: #151

Discussed in the 4 March 2019 meeting

Updated: VertexBufferState -> VertexInput, and rebased.

Sorry, didn't reevaluate the alternatives yet.

Assuming GPUVertexBufferDescriptor has defaults:

dictionary GPUVertexBufferDescriptor {
    u64 stride = 0;
    GPUInputStepMode stepMode = "vertex";
    sequence<GPUVertexAttributeDescriptor> attributes = [];
};

things still look kind of ugly in cases when there are holes:

const vertexBuffers = [vb0, {}, {}, {}, {}, {}, {}, vb7];

WDYT?

I can't stress this enough - this isn't the case to optimize usability for. Users who want many different vertex buffers mixed and matched in their pipelines can find ways for this to be sound, i.e.

var vertexBuffers = Array(MAX_VERTEX_BUFFERS).fill({});
vertexBuffers[0] = vb0;
vertexBuffers[7] = vb7;

Another issue is that this does not work for other sequences in the API. So we need to come up with something for those, too.

• GPUBindGroupLayoutDescriptor.bindings
• GPUBindGroupDescriptor.bindings
• GPUPipelineLayoutDescriptor.bindGroupLayouts
• GPURenderPipelineDescriptor.colorStates
• GPURenderPassDescriptor.colorAttachments

(not 100% sure everything on this list has the problem)

@kainino0x vertex buffers are different from the all the states you mentioned in that they are bound in ranges (e.g. we can bind all the vertex buffers from slot 1 to slot 4 in one command).

Stuff like GPUBindGroupDescriptor.bindings (vs GPUBindGroupLayoutDescriptor.bindings) refers to arbitrary binding points in the shader that are not in a specific range and no expectation is provided that they are near each other.

GPUPipelineLayoutDescriptor.bindGroupLayouts is already a sequence that is ordered by the bind group ID. We currently don't have a way of saying that a particular ID isn't used, so I think we just need to turn those into nullable, i.e.

dictionary GPUPipelineLayoutDescriptor {
    sequence<GPUBindGroupLayout?> bindGroupLayouts;
};

GPURenderPipelineDescriptor.colorStates and GPURenderPassDescriptor.colorAttachments - I don't see how the holes would be useful there at all, so we don't need any defaults.

Ok, I think I agree with you about bindGroupLayouts and colorStates/colorAttachments.

The GPUBindGroupDescriptor and GPUBindGroupLayoutDescriptor, though, currently use the [{binding: 0, ...}, {binding: 1, ...}] style. For BindGroupDescriptor, unfortunately BindGroupBinding doesn't have a good default value the way GPUVertexBufferDescriptor does. I don't see why it should be different from vertex input. There are two obvious options aside from what we have now:

dictionary GPUBindGroupBinding {
    required GPUBindingResource resource;
};

dictionary GPUBindGroupDescriptor {
    GPUBindGroupLayout layout;
    sequence<GPUBindGroupBinding?> bindings;
};

dictionary GPUBindGroupBinding {
    GPUBindingResource resource = null;
};

dictionary GPUBindGroupDescriptor {
    GPUBindGroupLayout layout;
    sequence<GPUBindGroupBinding> bindings;
};

Or even:

dictionary GPUBindGroupBinding {
   required GPUBindingResource resource;
};

dictionary GPUBindGroupDescriptor {
    GPUBindGroupLayout layout;
    object bindings;
};

(😛)

@kainino0x we need to talk about the order of bindings in a bind group. As it stands right now, they are defined individually (in GPUBindGroupLayoutDescriptor) and provided individually (in GPUBindGroupDescriptor), which is different from how the vertex buffers are provided (sequentially).

There is a case to be made about sequential binding IDs for the following reason:

• Vulkan API works with ranges of descriptors, so this would be potential optimization (disclaimer: nothing stops us from doing this today, but exposing an API that favors sequential bindings would hit this code path more often)
• depends on how we decide to expose arrays in inside descriptors. In DX12 and Metal each array element occupies a separate ID (in the respective heap or an MTLArgumentBuffer). In Vulkan the array dimension is extra (i.e full address of a descriptor consists of the trio (set, binding, array_index)).
• is there a good use case where this would be limiting?

Discussed at 25 March teleconference

TODO(me): Agreed to update this to Option 3 (here).

@kvark since I've closed this, would you mind posting your last comment as an issue or PR?

@kainino0x moved to #251