Provide the attachments state when starting a render pass - #92

Clarification to the second point: we can't actually use the render pass directly created for WebGPUAttachmentsState, since it doesn't know about the clear colors (and begin/end image layouts). Instead, we'll need to keep a set of render passes based on those varyings. The attachment state would still be the best place to own this set, so my second point is still relevant.

I don't think we want to do this: the consensus in the group was to go with "fat pipeline objects" so WebGPUAttachmentsState wouldn't be a standalone object but instead the attachment formats and sample counts would be somewhere in the WebGPURenderPassDescriptortree.

This would mean implementation need to keep a cache of renderpasses see for example this part of Dawn https://dawn.googlesource.com/dawn/+/master/src/dawn_native/vulkan/RenderPassCache.h

@Kangz wait, do you mean that you want to remove the WebGPUAttacmentsState completely? I find it quite elegant as it is now:

• it clearly defines a base VkRederPass, so that if the user creates pipelines A and B from it, they will be compatible with the customized render passes produced (and cached) by begin_render_pass.

"fat pipeline objects"

Can you remind me of what this means for us? A WeGPUPipelineState no longer corresponding 1:1 to the native pipeline?

This would mean implementation need to keep a cache of renderpasses

Right, I do agree that somewhere there's got to be a cache of renderpasses, as I indicated in the previous comment. However, I don't quite like the idea of a global cache per device, as done in Dawn. If WebGPUAttachmentsState is provided to begin_render_pass, it can own the cache of render passes, identified by a smaller key (can safely exclude the formats from it).

Yes I suggest removing WebGPUAttachmentsState as a separate object, and instead have it part of a "sub-descriptor" of WebGPURenderPipelineDescriptor.

Right now pipeline objects are made of a number of pre-built objects like WebGPUAttachmentsState, WebGPUBlendState, etc. The group didn't want to have partially built-objects and instead wanted WebGPURenderPipeline to be a large descriptor with sub-descriptors (except for the pipeline layout and shader modules).

@Kangz ok, that "fat pipeline object" definition is fine, but I'd argue that the attachments state is not a part of the render pipeline descriptor. The relation should be one to many, as in: a single WebGPUAttachmentsState would correspond to multiple rendering pipelines that are made with it. In that sense, it's more similar to the pipeline layout (in terms of relation to the WebGPURenderPipelineDescriptor) than to the blend/depth/other states. Therefore, I don't think WebGPUAttachmentsState should be affected by the upcoming "fat pipeline object" cleanup.

This is fair, how about we discuss it quickly in the next meeting? Either way would work well for us.

@Kangz sure! Too bad our next meeting is in a whole week from now :/
@RafaelCintron @litherum do you have a strong opinion/preference on the matter?

dictionary WebGPURenderPassColorAttachmentDescriptor {
    WebGPUTextureView attachment;
    ...
 };
dictionary WebGPURenderPassDescriptor {
    WebGPUAttachmentsState attachmentsState;
    sequence<WebGPURenderPassColorAttachmentDescriptor> colorAttachments;
    ...
};

Seems redundant. If we know what the textures are themselves, there's no need to pass in an attachmentsState.

Right now, WebGPUAttachmentsStateDescriptor only includes sequence<WebGPUTextureFormatEnum> formats. If I remember correctly, there was some discussion last time about multisampling; this topic might be easier to discuss if we first determine the rest of the contents of the WebGPUAttachmentsStateDescriptor object.

Closing in favor of #102, which we agreed on during the call. Thanks everyone for feedback!