We need to make a decision on what the attachments state is, and how it should be used. It's not obvious, and it may set a precedent for other states to follow (e.g. bind groups).
Proposals
Approach A: strictly unique handles. The user creates an attachments state via WebGPUDevice, this handle has to be specified for both the render pipeline creation and the beginning of a render pass. This is implemented in #92.
Approach B: non-unique handles. The user still creates an attachments state via the device, but it can use different handles for render pipeline creation, and it's not provided at the beginning of a render pass. The workload is valid as long as the descriptors used for the WebGPUAttachmensState handles, which were used for the render pipeline creation, match the data provided at the beginning of a render pass. Also can be called "by-value" semantics (as opposed to "by-pointer").
Approach C: no handles. The user provides all the data (that defines Vulkan render pass compatibility) in-place when creating a render pipeline, and when beginning a render pass. The workload is valid if the attachments are compatible between that pass and pipelines used in it. This is implemented in #102.
We need to make a decision on what the attachments state is, and how it should be used. It's not obvious, and it may set a precedent for other states to follow (e.g. bind groups).
Proposals
Approach A: strictly unique handles. The user creates an attachments state via
WebGPUDevice, this handle has to be specified for both the render pipeline creation and the beginning of a render pass. This is implemented in #92.Approach B: non-unique handles. The user still creates an attachments state via the device, but it can use different handles for render pipeline creation, and it's not provided at the beginning of a render pass. The workload is valid as long as the descriptors used for the
WebGPUAttachmensStatehandles, which were used for the render pipeline creation, match the data provided at the beginning of a render pass. Also can be called "by-value" semantics (as opposed to "by-pointer").Approach C: no handles. The user provides all the data (that defines Vulkan render pass compatibility) in-place when creating a render pipeline, and when beginning a render pass. The workload is valid if the attachments are compatible between that pass and pipelines used in it. This is implemented in #102.