Created attachment 120280 [details] Before a buggy draw call I noticed a few games had some strange artifacts on my tonga that I had not on verde. Those artifacts are usually along lines. These artifacts disappear with R600_DEBUG=nodcc. I managed to determine the bug appears when the render target is also used as input texture. Attached is the render target content before and after such draw call. The draw call draws two triangles. We can see the artifacts are along the border region of the top right triangle with the bottom left triangle. My guess is that it is some flush issue. That the bottom left triangle is drawn first, the cache content of the texture cache updated, and the artifacts are at locations where the dcc data was updated.
Created attachment 120281 [details] After a buggy draw call
Created attachment 120282 [details] Before a buggy draw call Repost of the first image, reported as PNG instead of text.
What happens if you set these flush flags after every draw call? SI_CONTEXT_FLUSH_AND_INV_FRAMEBUFFER SI_CONTEXT_INV_GLOBAL_L2 SI_CONTEXT_INV_VMEM_L1 SI_CONTEXT_PS_PARTIAL_FLUSH
I added these at the end of si_emit_draw_packets. It doesn't solve the problem.
I think we have cache coherency issues within a single draw call. One of the situations in which a feedback loop is allowed is if we read and write every texel at most once and we read the texel from the fragment shader invocation that writes that texel. My guess is that this is the case here, with two triangles. The problem is that while every pixel is written at most once, every block of pixels can be modified multiple times on the edges of a triangle. This results in garbage if a later invocation for a tile sees modified pixel data but stale DCC compression data, or stale pixel data and modified DCC compression data. This can be fixed by decompressing the framebuffer and disabling DCC decompression for the framebuffer. I would like to avoid decompressing, but I do not know how.
Does the series available at https://patchwork.freedesktop.org/series/8048/ fix this issue?
(In reply to Bas Nieuwenhuizen from comment #6) > Does the series available at > > https://patchwork.freedesktop.org/series/8048/ > > fix this issue? Hi Axel, those patches landed a long time ago. Is this issue still happening or can we close this bug?
The bug seems indeed to have been corrected since.
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.