<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED FIXED - [apitrace] Graphical artifacts in Civilization VI on RX Vega" href="https://bugs.freedesktop.org/show_bug.cgi?id=104602#c21">Comment # 21</a> on <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED FIXED - [apitrace] Graphical artifacts in Civilization VI on RX Vega" href="https://bugs.freedesktop.org/show_bug.cgi?id=104602">bug 104602</a> from <a class="email" href="mailto:jason@jasonplayne.com" title="Jason Playne <jason@jasonplayne.com>"> Jason Playne</a> <pre>(In reply to Connor Abbott from <a href="show_bug.cgi?id=104602#c20">comment #20</a>) > I wanted to make sure that improving the NIR path to reach parity with TGSI > in local variable handling wouldn't break things, so I investigated this a > bit more. It seems this is triggered by the fact that on Vega the TGSI path > always uses scratch, even for smaller local arrays. This bloats the scratch > space used by the VS in question. There are three back-to-back draw calls > with this VS (used to build up the map), each using scratch, and it seems > that radeonsi doesn't properly wait for each call to be done before starting > the next and reuses the same scratch buffer, resulting in the threads from > one draw call overwriting the scratch of the previous call. Hacking > si_update_spi_tmpring_size() to always allocate a new scratch buffer "fixes" > the black triangles. Thanks heaps for looking into the issue Conner. Looking at the explanation on what was happening makes it sound simple - I am sure the debugging effort was far greater! <3</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>