Bug 105396 - tc compatible htile sets depth of htiles of discarded fragments to 1.0
Summary: tc compatible htile sets depth of htiles of discarded fragments to 1.0
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Vulkan/radeon (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: mesa-dev
QA Contact: mesa-dev
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-03-08 11:04 UTC by James Legg
Modified: 2018-06-14 09:38 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Renderdoc v1.0 capture (9.04 KB, application/x-renderdoc-capture)
2018-03-08 11:04 UTC, James Legg
Details
Source for application used in RenderDoc frame capture (9.28 KB, application/x-xz)
2018-03-08 11:05 UTC, James Legg
Details
Expected output (3.44 KB, image/png)
2018-06-08 16:28 UTC, James Legg
Details

Description James Legg 2018-03-08 11:04:23 UTC
Created attachment 137887 [details]
Renderdoc v1.0 capture

On RADV, when using a VK_FORMAT_D32_SFLOAT (or VK_FORMAT_D32_SFLOAT_S8_UINT) depth buffer cleared to 0.0, if a fragment shader discards all fragments in a cleared htile, the htile's depth can be set to 1.0, instead of keeping the clear value of 0.0.

The attached renderdoc capture reproduces the issue by clearing the depth buffer to 0.0 with vkCmdClearAttachments, then drawing a triangle in the upper left half of an image using a shader which discards fragments that lie outside of a semicircle. The bug doesn't reproduce if I remove the vkCmdClearAttachments and use VK_LOAD_OP_CLEAR at the start of the render pass. However I have another more complex application which appears to be using VK_LOAD_OP_CLEAR in an earlier renderpass and loading stored depth values in a renderpass which reproduces this bug, without using other clears in the middle.

I'm using git revision fb5825e7ceeb16ac05f870ffe1e5a5daa09e68dd on an AMD RX 480.
Setting RADV_DEBUG to nohiz or nofastclears avoids the bug.
Comment 1 James Legg 2018-03-08 11:05:16 UTC
Created attachment 137888 [details]
Source for application used in RenderDoc frame capture
Comment 2 James Legg 2018-03-14 16:21:52 UTC
https://patchwork.freedesktop.org/patch/208935/ fixes it for me on my RX 480, but I haven't had any reviews on that patch yet and I'm not sure if I'm heading in the right direction. It would also be good to test this on other GPUs including Vega.
Comment 3 Samuel Pitoiset 2018-06-08 16:18:53 UTC
What should be the expected output?
Comment 4 James Legg 2018-06-08 16:28:25 UTC
Created attachment 140095 [details]
Expected output

A white semicircle on a black background, as shown.
Comment 5 James Legg 2018-06-08 16:34:37 UTC
Sorry, the more problematic bit is the depth buffer, which should be 0.5 inside the semicircle and 0.0 outside it, which isn't what is shown in the screenshot.
Comment 6 Samuel Pitoiset 2018-06-08 16:42:08 UTC
Looks like the output is correct on my polaris with mesa master, can you confirm?
Comment 7 Samuel Pitoiset 2018-06-08 16:44:47 UTC
Ah okay, sorry I missed your latest comment.
Comment 8 Samuel Pitoiset 2018-06-08 16:47:59 UTC
Okay, I can reproduce the issue with renderdoc, thanks!
Comment 9 Samuel Pitoiset 2018-06-13 10:06:32 UTC
Can you confirm this patch fixes the issue ? https://patchwork.freedesktop.org/patch/229236/
Comment 10 James Legg 2018-06-13 10:36:33 UTC
Yes, that patch fixes it. Thanks.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.