[Mesa-dev] [Bug 110603] Blocky and black opacity/alpha using RADV on some games

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=110603

--- Comment #8 from tivoboma at hostguru.top ---
Created attachment 144898
  --> https://bugs.freedesktop.org/attachment.cgi?id=144898&action=edit
Some notable parts of a renderdoc capture

I tried to get a renderdoc capture, but the results are way too large for my
internet connection to upload. I thus took a capture with and without nohiz,
and compared the two for obvious differences. I still have the captures, so if
there is anything specific I should look at I can do that.

The two things that stood out for me the most (refer to the attached zip for
the images I refer to):


1. DS=Store / DS=Load inconsistencies
In the first pass yielding visually different results, there are a few
instances of the following sequence:
> vkCmdEndRenderPass(DS=Store)      | a
> ...                               | b
> vkCmdEndRenderPass(DS=Load)       | c
> vkCmdDrawIndexed                  | d
In the good render (nohiz set), the DS keeps its content throughout a-c, and is
updated in d. In the bad render (nohiz not set), the DS gets weird fragments in
b, which usually go away in d – but in at least one case they did *not* go
away, causing the resulting texture to become visually corrupted (many pixels
become white, see 0_depth_attachment_after_load_*).

2. The final depth buffer is obviously wrong
The blocks visible on the final output are visible as white (near) in the final
depth pass. This seems to block the skybox/background from being added later on
(see 1_final_depth_*).

3. It seems that the good and bad render use slightly different render paths
While I could map most parts of the captures onto each other, there were some
additional render passes here and there that did not have clear equivalents in
the other capture – and are not obviously related to the different camera
position, etc.

4. The captures seem to be very hardware-dependent
For some reason, the nohiz capture only works if I set nohiz, otherwise
renderdoc claims that I use different hardware and I thus cannot view the
capture. Not sure if that is intentional, or if that is some clue that
something is wrong.


The final render results are 2_final_result_*. Note that even without nohiz,
some frames render properly – suggesting that the issue could be some kind of
data race, maybe between DS=Store/DS=Load?

Hope these comments help at least a little, sorry that I'm unable to provide
the whole captures.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20190728/fb2f6500/attachment.html>