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?
best, -mario
********************************************************************* Mario Kleiner Max Planck Institute for Biological Cybernetics Spemannstr. 38 72076 Tuebingen Germany
e-mail: mario.kleiner@tuebingen.mpg.de office: +49 (0)7071/601-1623 fax: +49 (0)7071/601-616 www: http://www.kyb.tuebingen.mpg.de/~kleinerm ********************************************************************* "For a successful technology, reality must take precedence over public relations, for Nature cannot be fooled." (Richard Feynman)
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.
On Jun 4, 2010, at 7:27 PM, Michel Dänzer wrote:
On Mit, 2010-06-02 at 16:38 +0200, Mario Kleiner wrote:
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.
I think that is what the Intel drm does. Your dri2-flicker-mesa.diff patch makes sense to me as a newbie with limited understanding. If this ends up calling DRI2GetBuffers... in the server, it will block in DRI2ThrottleClient until the swap completes.
I doubt that the dri2-flicker-xf86-video-ati.diff patch has a real effect? For a regular glXSwapBuffers() command, the code-path isn't taken, where you placed the DRI2BlockClient() call, so it can't have an effect. If it would be taken as part of some call to the new glXSwapBuffersMscOML() function, it would likely do bad things(tm) which are against the purpose of this new extension.
-mario
********************************************************************* Mario Kleiner Max Planck Institute for Biological Cybernetics Spemannstr. 38 72076 Tuebingen Germany
e-mail: mario.kleiner@tuebingen.mpg.de office: +49 (0)7071/601-1623 fax: +49 (0)7071/601-616 www: http://www.kyb.tuebingen.mpg.de/~kleinerm ********************************************************************* "For a successful technology, reality must take precedence over public relations, for Nature cannot be fooled." (Richard Feynman)
dri-devel@lists.freedesktop.org
-
Mario Kleiner -
Michel Dänzer