CI Flakes on VK discarding_either_depth_or_stencil_aspect_test

[cwfitzgerald]

  TRY 3 FAIL [   0.460s] wgpu-test::gpu-tests [Executed] [Vulkan/llvmpipe (LLVM 15.0.7, 256 bits)/0] gpu_tests::zero_init_texture_after_discard::discarding_either_depth_or_stencil_aspect_test

thread '<unnamed>' panicked at 'texture was not fully cleared', tests/tests/zero_init_texture_after_discard.rs:306:9

https://github.com/gfx-rs/wgpu/actions/runs/6947331918/job/18900887783?pr=4723

[teoxoy]

Related: #4739 & #4245

[teoxoy]

If we revert the changes to the test (#4739), it seems to be broken on MoltenVK as well and even D3D12 #4739 (comment).

Looking at the errors thrown by Vulkan & D3D12, I suspect part of the texture tracking code is not working properly.

[cwfitzgerald]

Yeah, something weird is going on here. When the resource is finally uses as copy_src after initialization, the device tracker thinks it hasn't seen it and just inserts the state without inserting a barrier at all.

[cwfitzgerald]

We end up in https://github.com/gfx-rs/wgpu/blob/trunk/wgpu-core/src/track/texture.rs#L404-L436 during triage_suspected for the texture. external_count == 2 and the existing_ref_count == 2 and 2 <= 1 + 2, so the texture gets removed from the tracker, despite the texture being very much alive.

[cwfitzgerald]

This part of the tracking and maintenance code is new after arcinization, so is new to me, still getting up to speed. cc @gents83

[cwfitzgerald]

The difference is which submission each submission is determined done at. If the submission is determined finished in the same submit call the texture will be removed.

The order of operations is:

• Build submission
• Submit
• Do some stuff
• Maintain.

If the maintain call finds that the submission they just kicked off is done, you'll get

Texture Id { index: 0, epoch: 1, backend: Vulkan } is not tracked anymore due to ref count 3. External count: 2 every single submission.

If a submission lasts until the next submit call, you'll get:

Texture Id { index: 0, epoch: 1, backend: Vulkan } is still referenced with ref count 4. External count: 2 instead.

log-success.txt
log-fail.txt

Also go our logging!

[gents83]

Yep! The situation is exactly as you described. In some situations the texture is not referenced and so can be released at the end of the frame.

When I was investigating this anyway I had the impression that when submitting right every operations the barrier transition operation doesn't work as intended.
While if all operations are in the same sumbit the resource state is following the correct flow.

So I think that our best option is to add some logging to barriers and transitions to check what is going on in that sense probably

[cwfitzgerald]

When I was investigating this anyway I had the impression that when submitting right every operations the barrier transition operation doesn't work as intended.
While if all operations are in the same sumbit the resource state is following the correct flow.

The only reason it's not working as intended is that the trackers are removing the textures every frame from the trackers. If that didn't happen the barriers would be correct.

So I think that our best option is to add some logging to barriers and transitions to check what is going on in that sense probably

It already does :)