PC Graphics

[Duttenheim]

Hello everyone, I keep seeing these artifacts when trying to store an MSAA depth target from one pass, and then use it for depth equals or less-equals tests (without write) later: 

The first render pass outputs an MSAA depth buffer, with a clear and store op on the depth, as well as a resolve for a depth mip reduction later. The second pass loads the MSAA depth texture and is supposed to use it for depth tests only, and this is where I see these artifacts. In the above picture, less equals tests are used, but if I use only equals tests, only a few blocks of pixels get shaded. 

Does anyone know why this is? Running the depth in the same pass as the lighting works just fine by the way.

Thanks!

[Duttenheim]

Okay so, did some digging these past days and I can't say definitively what is going on, but I did find a workaround.

So, all passes expect VK_IMAGE_LAYOUT_DEPTH_STENCIL_READ_ONLY_OPTIMAL as both initial and final layout on depth buffers. This works fine if the attachment is not MSAA. However, when using MSAA, this results in a CmdDepthStencilExpand on the driver side when using RGP to inspect the events, and I am wondering if this is causing the issue. When debugging with RenderDoc, it shows that for some samples, the pixel shader outputs black. However, creating a copy of the same depth buffer and rendering to it in both passes show identical data per fragment. I can confirm this is due to a failed depth test because using VK_COMPARE_OP_LESS_EQUAL makes more fragments pass the test (not all) and using VK_COMPARE_OP_ALWAYS doesn't produce this artifact at all. 

Changing the final layout to be VK_IMAGE_LAYOUT_DEPTH_ATTACHMENT_OPTIMAL fixes the issue. This smells like a bug on the driver side but can't say for sure. It doesn't violate the spec and so no validation errors are thrown. 

Thanks.

[goodplay]

You might want to post (and have the topic moved) to 'Communities > Developers' section.