We've been going back and forth on the need for render/compute/blit passes, and I'd like to systematize the arguments and suggest models we could navigate from.

In native APIs, Vulkan has render passes only, Metal requires all the work to be done in one of the blit/compute/render pass. And D3D12 does not have any passes yet.

Here are the major areas (I can think of) that could take advantage of a pass concept, and the ideas on how they might be relevant to WebGPU:

Resource bindings inheritance - #24

In Metal, resource bindings are only valid with the scope of a pass, where in Vulkan/D3D12 they are scoped to command buffers. This allows Metal runtime/driver to allocate descriptors based on everything used in a pass. This isn't a benefit for WebGPU, given that we have explicit resource bind groups created by the user.

Synchronization and validation - #27, #59

In Vulkan the memory barriers and layout transitions are explicit. In D3D12 the resource state transitions as well as UAV/aliasing barriers are mostly explicit, but there are rules for automatic to/from conversion to the "common" state. In Metal, memory barriers are mostly implicit. They are inserted automatically at the render pass boundaries, around individual dispatch and transfer calls.

For WebGPU, we decided to not expose the memory barriers in the API, and thus we can insert the appropriate synchronization commands between passes. In order for this to be valid, we introduce the "Usage" (mutable) state of a resource and declare a requirement of each resource having a constant usage across a pass. However, we also decided to automatically synchronize individual dispatch (UAV barriers only) and transfer calls, much like Metal. It isn't a long stretch to go from here to a full synchronization (allowing layout changes, for example), in which case the construct of a compute and transfer pass stops being useful (in the context of memory barriers).

Work scheduling - #22

Hardware queues on Vulkan and D3D12 are explicit. In Metal, the MTLCommandQueue is also exposed, but it doesn't have a direct relation to a hardware queue. Metal runtime figures out the dependencies between passes (which is sound, given that all the work is split into passes) and reserves the right to actually execute them on different hardware queues (note: how much this is the case in reality is unknown to me).

In WebGPU we decided to not expose the hardware queues, thus I find the opportunity of automatically taking advantage of them to be quite strong to miss.

Type safety

Each kind of a pass has a restricted set of operations that can be recorded. E.g. one can't dispatch() or bind compute resources in a MTLBlitCommandEncoder pass. This makes the API more usable, assists documentation, and is generally is a good practice for API design.