Flickering screen in Neverball on drm-radeon-testing

[Michel Dänzer]

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 at freedesktop.org
> > Subject: [Bug 28341] Flickering screen in Neverball on
> > 	drm-radeon-testing
> > To: dri-devel at lists.freedesktop.org
> > Message-ID: <20100601192542.ACE5B1300E8 at 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 at 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.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dri2-flicker-mesa.diff
Type: text/x-patch
Size: 576 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20100604/fdfc48ce/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dri2-flicker-xf86-video-ati.diff
Type: text/x-patch
Size: 391 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20100604/fdfc48ce/attachment-0001.bin>