Bugzilla – Bug 32845
Sandybridge: Line rendering (buffer length/offset?) issues, including crashes
Last modified: 2011-03-09 14:51:38 UTC
The xscreensaver "klein" shows some rendering artifacts in line mode, which let me assume that there are some buffer length / offset / number of primitives issues with OpenGL lines. Please note the attached screenshot.
Using this screen saver we get GPU freezes during S3 stress tests, after approx. 20-500 S3 cycles. When using multiple OpenGL apps at the same time, this tends to be reproducible earlier. I assume this is related to the rendering issue (out-of-buffer accesses), but cannot be sure.
In one case we had an obvious GPU freeze (xterm didn't output anything any more, also the desktop), but the "klein" screensaver was still running, overnight! It only froze when I tried to start up another xterm for viewing logs on the next morning... This was one of the more obscure freezes I had in my live...
drm of 2.6.37rc7
xf86-video-intel pre-2.14 git 1ac2e04
Mesa pre-7.10 git 4e8f123
Created attachment 41662 [details]
Screenshot of the "klein" screensaver
'klein' has many subcases, what specific options you use in rendering failure case?
All pure line rendering subsystems are affected.
I created a test case, attaching it here. GL_LINE_LOOP with >=3000 line segments shows this bug.
Created attachment 41882 [details]
GL_LINE_LOOP test case
Running this test case should display a (slightly flashing) circle, and nothing else.
The freeze might actually be related to
but doesn't have to.
(In reply to comment #5)
> The freeze might actually be related to
Any news on this? Has anybody verified that the test case shows the same issue for them?
I had the exact same issue with sandybridge using gl_line/line_loop_line_strip.
I was able to recreate it just drawing large hallow circles.
It was fixed in Bug 29172
*** This bug has been marked as a duplicate of bug 29172 ***