Currently, each and every operation on a command encoder or a pass goes directly into the driver. This was done with the intention of having minimal overhead and maximum simplicity. However, I don't think the effort is paying off: each pass operation still has to switch on the backend type and (more importantly) lock at least one storage (e.g. for the pass).

This approach is not feasible for powering WebGPU implementation in Gecko, where wgpu leaves in a separate process, and thus direct low-overhead access on each command is not an option.

From the early days, the plan was to have "software" passes recorded on the client side and then actually provided to wgpu on a command-by-command basis on the server (after crossing the IPC). The idea was that we'd figure out all the usage across the pass, so that we can optionally pass that when we start the pass, telling wgpu to not bother inserting transitions and instead just validate that the given usages are correct.

The problems here are many, as it turns out now:

1. recording command-by-command still suffers from the overhead
2. having different code paths in wgpu-core for pass recording is a major complication

Fortunately, I believe these are solvable. My suggestion is to move to software passes consistently everywhere, not just for Gecko implementation. This would give us the following advantages:

• simpler and more unified code for pass recording
• strictly one native command buffer per wgpu command buffer (unlike today, where each pass ends up being a native command buffer, and we insert more for stitching...)
• solves Single-recording mode for passes #89
• makes Capturing internal state for debug investigations #72 easier
• potentially faster recording of commands
• potential for recording passes on multiple threads
• potential for re-using passes (as an alternative to bundles and/or re-usable command buffers)