https://bugs.freedesktop.org/show_bug.cgi?id=28341 Mario Kleiner <mario.kleiner@xxxxxxxxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mario.kleiner@xxxxxxxxxxxxx | |.de --- Comment #8 from Mario Kleiner <mario.kleiner@xxxxxxxxxxxxxxxx> 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. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
