This is Mozilla's new proposal for #64. The core of the proposal is to have the command buffer semantic equivalent of the one provided by the native API, and have render and compute passes similar to Metal.

The command buffer is the unit of submission of work to GPU. It could be created as "re-usable" to allow multiple submissions, or "one-time" for it being consumed by the submission. A command buffer API consists of the following parts:

• begin/end of a render pass with specified targets. Beginning a render pass returns a render pass encoder that is used for encoding draw states and commands. While the encoder is active, i.e. between it's creation and finish() call, no other commands are permitted on the command buffer (it's considered uniquely borrowed).
• begin/end of a compute pass. Similarly, a compute pass is encoded via a separate API object (compute encoder) that has methods for state setting and dispatch calls. A compute pass also borrows the command buffer uniquely for it's lifetime (until the finish() method is invoked).
• transfer commands, such as filling buffers or images, copying data between them.

Both compute and render encoder API objects would inherit from a common interface (e.g. WebGPUResourceEncoder, naming is hard) that has methods for binding resource groups and pipeline states. We believe this makes up for a good class hierarchy and strong typing.

Reasons to not have transfer/blit passes:

1. unlike render/compute, they don't have the resource context, and consequently can't derive from WebGPUResourceEncoder
2. unlike render/compute, they don't enforce the constant resource usage of all the participating resources
3. some of the "transfer" operations, like clearing an image, may have to translate to Metal render passes, which means there couldn't be a 1:1 relationship between WebGPU transfer passes and Metal backend passes

If we go back to the concerns expressed in #64, here is what we get with this proposal:

• "Resource bindings inheritance" - no inheritance, resource binding is encapsulated withing render/compute passes
• "Synchronization and validation" - a command buffer operation becomes our unit of synchronization, plus some extra UAV barriers within a compute pass.
• "Work scheduling" - there is still an option for the backend to use multiple queues
• "Command re-usal" (not listed there, but needs to be) - the proposal makes a clear path for re-usable command buffers, while leaving the bundles/secondary command buffers for later.
• "Type safety" - we all the benefits of type safety