| Bug ID | 93216 |
|---|---|
| Summary | Artifacts with DCC when render target also texture |
| Product | Mesa |
| Version | git |
| Hardware | Other |
| OS | All |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | Drivers/Gallium/radeonsi |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | axel.davy@ens.fr |
| QA Contact | dri-devel@lists.freedesktop.org |
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.
| What | Removed | Added |
|---|---|---|
| Attachment #120280 is obsolete | 1 |
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 cal= l? 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://patchwor= k.freedesktop.org/series/8048/ fix this issue?
| What | Removed | Added |
|---|---|---|
| Status | NEW | NEEDINFO |
(In reply to Bas Nieuwenhuizen from comment #6) > Does the series available at >=20 > https://pat= chwork.freedesktop.org/series/8048/ >=20 > fix this issue? Hi Axel, those patches landed a long time ago. Is this issue still happenin= g or can we close this bug?
| What | Removed | Added |
|---|---|---|
| Resolution | --- | FIXED |
| Status | NEEDINFO | RESOLVED |