Ok, I think I see what's happening now. The allocator is still shared between command buffers, but since we didn't call Reset() on it before, it only resulted in a validation warning/error. Now we call Reset on it whenever any of the command buffers are reset, and this only works within the assumption that no 2 command buffers are recorded at the same time. Since this is not the case in wgpu-rs, we are crashing now.

The proper solution would be one (or both) of the two:

1. fix the dx12 backend to not require only a single command buffer being recorded
2. implement a path in wgpu-rs to not keep the old command buffer in the open state

bors r+

While this needs to be ported to hal-0.1 at some point, this is not going to improve the situation with wgpu-rs. So I think we need to fix wgpu-rs first, and then think about back-porting this.

Important note: what this is solving is resource leaks in case of simple applications. It's less forgiving for the others (turning warnings into crashes). We'll need a proper solution for DX12 backend regardless, at which point this PR will be reconsidered and/or reverted.

Build succeeded

• continuous-integration/travis-ci/push

I'm a bit confused. If each command buffer comes with an allocator, why do we still suffer from the reset() in wgpu?

right, there are actually 2 different issues depending on what is used and I mixed those up :D

• Path A: Shared/NoIndividualReset: No memory leaks, but no support for concurrent recording

• Path B: Individual/Reset: Memory leaks (fixed with this one), supports concurrent recording, but doesn't implement state tracking for command buffer state

Command Buffer Lifecycles

CommandList::Reset in dx12 has a reset+begin semantic for commands buffers (-> Recording state), in Vulkan Reset means setting it back into Initial State and begin we can move from Initial to Recording, but Begin also can have a reset semantic when individual reset is allowed. Back to the issue, reset + begin in vulkan works fine (cur state -> Initial -> Recording), transferring this into dx12 would mean (cur state -> recording -> recording!), which is not legal)

Thanks for clarifying! So we do have dedicated command allocators for the command buffers that are individually reset?

CommandList::Reset in dx12 has a reset+begin semantic for commands buffers

Sounds like we are missing just a few bits then (what you said to be the state tracking):

• on reset() just reset the command allocator and close the command buffer is it's being recorded
• on begin() actually call CommandList::Reset