Bug 102488

Summary: radv_handle_depth_image_transition() wrongly clearing depth data when transitioning to htile.
Product: Mesa Reporter: xbx <xavierb>
Component: Drivers/Vulkan/radeonAssignee: mesa-dev
Status: RESOLVED NOTABUG QA Contact: mesa-dev
Severity: normal    
Priority: medium    
Version: git   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments: proposed fix

Description xbx 2017-08-31 08:11:04 UTC 
Created attachment 133895 [details] [review]
proposed fix

Hello,

I had a problem with a program doing manipulation of the depth buffer 
(to do downscaled rendering of part of the scene), and attached patch fixes it. 

However, I really have no idea of what the flush flags should be
(as they are different in radv_initialize_htile()), nor if it's the correct way 
nor if it should only apply in some cases...

I also tested that "Mad Max" still works.
Comment 1 Bas Nieuwenhuizen 2017-10-04 07:46:05 UTC 
Hi, does changing the integer in the transition from 0xffffffff to 0x30f instead fix the issue too?
Comment 2 xbx 2017-10-04 09:03:19 UTC 
Hi,

Yeah sorry I don't have a nice repro to send.

I'm pretty sure I did test this at the time, and it didn't work.  But I'll try again to make sure.

I don't remember the details precisely, but there general idea is:
 - part of the scene is rendered
 - then the z buffer is converted to a linear texture
 - downscaled with a shader to a new texture
 - the new texture is then converted back to a htile zbuffer(*)
 - and some more rendering is done at that lower resolution, in parts not occluded
 - and then all is blended together for presenting

So the problem is that the (*)transition does need to convert the data and not just clear the buffer.
Comment 3 Bas Nieuwenhuizen 2017-10-04 18:11:47 UTC 
Note that we are only setting the metadata though. 0x30f should be the metadata that means "data is uncompressed, just take the value from data", 0xffffffff is probably "clear to depth 1.0". 

You might even try just not setting any value at all, given in this transition you did a decompress previously, so the hardware might have set the metadata to something similar to 0x30f.
Comment 4 xbx 2017-10-05 07:49:49 UTC 
I did more testing.
And I think I'm getting mad.

When using master, it works.
It also works with 0x030f . (and it doesn't with 0x0000)

I did try 17.2 branch, also works.

The only way I could reproduce the bug in the application was messing with VK_ATTACHMENT_LOAD_OP_DONT_CARE / VK_IMAGE_LAYOUT_UNDEFINED ...
but that's because, then, it doesn't enter the if branch in radv_handle_depth_image_transition() at all.

So I don't know how I came up with this at the time.
sorry.

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.