On Mit, 2010-06-02 at 16:38 +0200, Mario Kleiner wrote:
Message: 1 Date: Tue, 1 Jun 2010 12:25:42 -0700 (PDT) From: bugzilla-daemon@freedesktop.org Subject: [Bug 28341] Flickering screen in Neverball on drm-radeon-testing To: dri-devel@lists.freedesktop.org Message-ID: 20100601192542.ACE5B1300E8@annarchy.freedesktop.org Content-Type: text/plain; charset="UTF-8"
https://bugs.freedesktop.org/show_bug.cgi?id=28341
--- Comment #3 from Magnus Jensen magnus@jensenligan.se 2010-06-01 12:25:42 PDT --- Sorry. ignore my last attachment. These errors continue to spawn and i don't think they are related to neverball. i'm going to recompile mesa and ddx, and post another dmesg soon. Just waiting for a kernel compile to finish.
I saw a similar flickering with latest Xorg stack (mesa master, xserver, ddx etc. master) and the 2.6.34 tree from radeon testing with my own toolkit on a R600 gpu. This setup uses the new dri sync & swap bits and changes how glXSwapbuffers works.
My best hunch would be that submission of new rendering commands by the direct rendering client to the gpu doesn't block after a glXSwapbuffers() call until the bufferswap completed, i.e., some synchronization is missing there.
This shows flickering, but load and timing dependent...
.... glXXX rendering commands to draw image. glXSwapBuffers(); glBegin(GL_POINTS); glVertex2i(10,10); glEnd(); glFinish(); Take a swap completion timestamp here. glClear(); ...more rendering commands
-> I use this glVertex2i, .... glFinish() sequence to wait for swap completion and get a timestamp. This works on any os/gpu combo ever tested, but doesn't seem to work reliably anymore with the new radeon sync & swap bits in place. Display flickers, presumably because the glClear() executes almost immediately after the glXSwapBuffers is scheduled, and before the bufferswap has actually taken place -> Clear the backbuffer before swapping.
This however:
.... glXXX rendering commands to draw image. glXSwapBuffers(); glXWaitForSbcOML(...); glClear(); ...
does work, because the new glXWaitForSbcOML() blocks the client until swap completion, so glClear() can only get submitted to the gpu after the swap completed.
[Except that glXWaitForSbcOML itself currently has a bug, for which i'll send a patch for xorg master/1.8.1 soon].
Didn't do detailed testing, but maybe this points into the right direction?
I think your analysis is spot on.
The ideal solution would probably be to make the kernel block in the command stream (CS) submission ioctl if the CS renders to (and from?) a buffer object (BO) which is involved in a pending swap.
Meanwhile, the attached hacks for xf86-video-ati and Mesa seem to help here, YMMV.