Bug 66558 - RS690: 3D artifacts when playing SuperTuxKart
RS690: 3D artifacts when playing SuperTuxKart
Status: RESOLVED FIXED
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/r300
git
x86-64 (AMD64) Linux (All)
: medium normal
Assigned To: mesa-dev
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-03 19:53 UTC by Björn Beutel
Modified: 2013-07-15 22:38 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Example of corruption in SuperTuxKart (584.61 KB, image/png)
2013-07-03 19:53 UTC, Björn Beutel
Details
glxinfo output (24.22 KB, text/plain)
2013-07-03 19:57 UTC, Björn Beutel
Details
dmesg output (48.77 KB, text/plain)
2013-07-03 19:57 UTC, Björn Beutel
Details
Patch that sets the needed CS buffer size in "r300_render_draw_elements" (967 bytes, patch)
2013-07-03 20:15 UTC, Björn Beutel
Details | Splinter Review
possible fix (6.01 KB, patch)
2013-07-15 14:01 UTC, Marek Olšák
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Björn Beutel 2013-07-03 19:53:53 UTC
Created attachment 81975 [details]
Example of corruption in SuperTuxKart

Using the 300g driver from Mesa 9.1, the SuperTuxKart game sometimes shows artifacts, as show in the attached example.
Comment 1 Björn Beutel 2013-07-03 19:57:10 UTC
Created attachment 81978 [details]
glxinfo output
Comment 2 Björn Beutel 2013-07-03 19:57:45 UTC
Created attachment 81979 [details]
dmesg output
Comment 3 Alex Deucher 2013-07-03 19:59:47 UTC
Is this a regression?  If so, can you bisect?
Comment 4 Björn Beutel 2013-07-03 20:15:42 UTC
Created attachment 81980 [details] [review]
Patch that sets the needed CS buffer size in "r300_render_draw_elements"

The attached patch solves the problem for me in Mesa 9.1 and Mesa Git.

For me, it seems as if the buffer is not always properly flushed in between when "r300_render_draw_elements" has to divide it into two or more runs.
Comment 5 Björn Beutel 2013-07-03 20:28:36 UTC
@Alex Deucher: 

AFAIK, that bug has been in r300g from its very beginnings (in contrast to r300c).
Comment 6 Alex Deucher 2013-07-14 15:48:52 UTC
Marek, any idea why r300_render_draw_elements() calls r300_prepare_for_rendering() with 256 dwords?
Comment 7 Marek Olšák 2013-07-14 20:18:36 UTC
The function splits the drawing into several packets if there are too many indices. 256 dwords is a reasonable minimum for the first packet. I think the problem arises when the splitting takes place in the middle of a primitive, breaking all the primitives that follow. I'll send a patch.
Comment 8 Marek Olšák 2013-07-15 14:01:14 UTC
Created attachment 82446 [details] [review]
possible fix

Please try this patch.
Comment 9 Björn Beutel 2013-07-15 18:28:16 UTC
Marek, your patch solves the problem for me. Thanks!
Comment 10 Marek Olšák 2013-07-15 22:38:21 UTC
I committed the patch as 22427640b248aeb9875b40b216d27bedb13a1db8. Closing.