<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Blocky and black opacity/alpha using RADV on some games" href="https://bugs.freedesktop.org/show_bug.cgi?id=110603#c8">Comment # 8</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Blocky and black opacity/alpha using RADV on some games" href="https://bugs.freedesktop.org/show_bug.cgi?id=110603">bug 110603</a> from <a class="email" href="mailto:tivoboma@hostguru.top" title="tivoboma@hostguru.top">tivoboma@hostguru.top</a> <pre>Created <a href="attachment.cgi?id=144898" name="attach_144898" title="Some notable parts of a renderdoc capture">attachment 144898</a> <a href="attachment.cgi?id=144898&action=edit" title="Some notable parts of a renderdoc capture">[details]</a> 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>