Previews, as seen at the time of posting this comment:
WebGPU | IDL
WGSL
_3cc422a

My concerns with this are:

• Slight extra verbosity is kind of meaningless for single-queue apps.
• Ties command buffer to a single queue instead of a whole queue family (even though we don't have such a concept in WebGPU now).
• What if we added some kind of "virtual" reusable command buffer in the future that wasn't tied to a queue? (Probably wouldn't happen.)

I think I'm slightly in favor of keeping createCommandEncoder where it is, but adding an optional GPUCommandEncoderDescriptor.queue member which defaults to defaultQueue. No strong opinion though.

+1 to @kainino0x's concerns. (and I think we'd like reusable command buffers at some point, but IDK how well it would work in wgpu to have them work for all queue types)

Let me try to downplay the concerns :)

Slight extra verbosity is kind of meaningless for single-queue apps.

Command encoders are created in only a few places by the code. Most command recording in the apps is expected to work with an existing encoder. So we are talking about just a few .defaultQueue additions, and that's assuming the users will not have the queue accessible separately (some will).

Ties command buffer to a single queue instead of a whole queue family (even though we don't have such a concept in WebGPU now)

Right. We could have a discussion about queue families. It would need to be resolved before we proceed with the PR.

What if we added some kind of "virtual" reusable command buffer in the future that wasn't tied to a queue?

First time I'm hearing about this. Note that "reusability" of command buffers can be implemented without the "virtual" aspect, and it will likely be more efficient, since it would use VkCommandBuffer and D3D12CommandList.

I think I'm slightly in favor of keeping createCommandEncoder where it is, but adding an optional queue member which defaults to defaultQueue

Are you talking about a member of GPUCommandEncoderDescriptor? I suppose it would be a nullable member then.
It sounds good in this case, I haven't thought of that.

Previews, as seen at the time of posting this comment:
WebGPU | IDL
WGSL
_0f05d2d

Consider this blocked on #1977

Editors discussion: we'd want to know how multi-queue works with queue families. If WebGPU exposes queue families, it would be a better API to have GPUCommandEncoderDescriptor knowing about the queue family, not the exact queue. This is not the same as creating the command encoder on a queue. Something like:

dictionary GPUCommandEncoderDescriptor {
  type: GPUCommandType, // "general", "compute", "transfer"
};

With this in mind, our recommendation is to not proceed with this PR for now. Instead, try to think more about how multi-queue is exposed, possibly basing off #1306 in the direction that DX12 does it.