Jim Blandy

In other words - we have this thread-safe API, so the whole point should be to make the user deal with that stuff. @kpreid, can't you just write your own...

Okay - I understand what I wasn't getting before. - The WebGPU `create*PipelineAsync` functions expose parallelism not otherwise available to web content: at least in today's browsers, content cannot just...

> Additionally, on WASM, the extra thread needed to initiate that pipeline creation is useless - the actual parallelization is happening in the GPU process, so an extra JS thread...

In case it matters: Firefox now permits depending on `windows-sys`, but still not `windows`. My understanding is that `windows-sys` does not offer COM API bindings, which are the ones we...

In Traverse-Research/gpu-allocator#181, they said they're cool going with a bindgen-based approach. So maybe we have a way forward here.

It seems like CI for #5222 hits this reliably in the `minimum_buffer_binding_size_dispatch` test.

Some background. This is not a coherent explanation of anything, just me writing down what seemed possibly relevant: Direct3D 12's complaint is that users are not permitted to call `ID3D12CommandAllocator::Reset`...

So I think all that's necessary for this bug to occur is for `wgpu_core` to call `reset_all` on a `CommandEncoder` while it's still got a currently recording command list ---...

I found a workaround for #5222, but https://github.com/jimblandy/wgpu/tree/repro-wgpu-3193 has the code that was crashing on CI.

Confirmed that that branch still crashes. That suggests that [this change](https://github.com/gfx-rs/wgpu/compare/319408941b4c7d8b5e21658022f40efb29f95fbb..7ffe93645952f9e579ff4fc0c6257c66c713cdb3) removed the behavior that triggers the bug.