cancel
Showing results for 
Search instead for 
Did you mean: 

OpenGL & Vulkan

Duttenheim
Adept I

Vulkan - Strange artifacts with MSAA depth buffer

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: 

Duttenheim_10-1664010932405.png

 

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!

0 Likes
5 Replies
Duttenheim
Adept I

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.

0 Likes

Hi! @Duttenheim for resolving Depth Buffer you should try to use VK_KHR_depth_stencil_resolve extension

0 Likes

Hello! Yeah I did but it didn’t matter, removing the depth resolve had no impact at all on the result. I was using vkCreateRenderPass2 with depth resolve, reverted to vkCreateRenderPass with a compute for resolve - same results. In any way, in the second pass I need the MSAA depth anyways, not the resolved result. 

Thanks.

0 Likes
Duttenheim
Adept I

@Andrey2007AMD If it would help, I can pass an .rgp trace with the issue and one without it. 

0 Likes

Hey Duttenheim,

That would be great, if you can also provide compilable source code which shows this issue that would speed it up on our end as well.

Thanks,

Owen

0 Likes