[Bug 28341] Flickering screen in Neverball on drm-radeon-testing

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=28341

Mario Kleiner <mario.kleiner at tuebingen.mpg.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mario.kleiner at tuebingen.mpg
                   |                            |.de

--- Comment #8 from Mario Kleiner <mario.kleiner at tuebingen.mpg.de> 2010-06-15 04:32:49 PDT ---
Seems that some synchronisation in the radeon kernel drm driver is missing,
which wasn't needed for the old synchronous vsync code;

Old glXSwapbuffers code was synchronous: glXSwapBuffers blocked until swap
completion.

The new code just schedules a vblank event, then returns control to the client.
The client submits further rendering commands into the command stream before
the swap has completed, so you have a race-condition between the client
submitting new commands for the post-swap backbuffer and the vblank event
triggering submission of the "bufferswap blit" command buffer into the cs a
couple of milliseconds after the glXSwapbuffers call. Depending on the relative
timeing, it can happen that *new* rendering commands, e.g., glClear() get
executed on the *old* backbuffer before it has been copied to the frontbuffer.
Would result in random flickering or half-rendered frames overdrawn on top of
old rendered frame.

The solution would be to add some synchronisation to the kernel driver: If a
swapbuffers is pending and a client tries to submit command buffers for that
drawable, block it until swap completion. This is what the intel drivers
apparently do and what seems to be missing fromt the radeon driver.

Michel Daenzer confirmed my suspicion with some patch (conversation on
dri-devel):

"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."

He added this patch to mesa inside the Dri2Swapbuffers submission code, after
the swap has been scheduled:

+
+    /* Make sure we call to the server before rendering again, in case we need
+     * to block for the swap */
+    dri2InvalidateBuffers(dpyPriv->dpy, pdraw->drawable);

This is what i found (also posted on dri-devel):

"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.

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."

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.