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

--- Comment #2 from Magnus Jensen magnus@jensenligan.se 2010-06-01 11:37:20 PDT --- Created an attachment (id=35995) --> (https://bugs.freedesktop.org/attachment.cgi?id=35995) dmesg/current

The last output from dmesg after running neverball for a few seconds. The notice about mesa being outdated is not valid in this case since, it still flickers whether i recompile mesa or not. I have got same error without that message.

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

Magnus Jensen magnus@jensenligan.se changed:

What |Removed |Added ---------------------------------------------------------------------------- Attachment #35995|0 |1 is obsolete| |

--- Comment #4 from Magnus Jensen magnus@jensenligan.se 2010-06-01 15:11:57 PDT --- Created an attachment (id=35997) --> (https://bugs.freedesktop.org/attachment.cgi?id=35997) dmesg-current

no radeon related stuff in dmesg output while running neverball (still flickers a lot) drm+mesa+ddx all latest from git. this do not occur with distro kernel (2.6.33.4)

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

--- Comment #6 from Alex Deucher agd5f@yahoo.com 2010-06-09 13:45:19 PDT --- possibly also related to bug 28383 and bug 28410.

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

Mario Kleiner mario.kleiner@tuebingen.mpg.de changed:

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

--- Comment #8 from Mario Kleiner mario.kleiner@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."

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

--- Comment #10 from Michel Dänzer michel@daenzer.net 2010-07-14 02:30:55 PDT --- Does reverting xf86-video-ati Git commit 30591320ec46e491ba20904cc64f3405b51c6505 ('kms: add support for the MSC swap & sync API') fix this problem?

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

--- Comment #12 from Michel Dänzer michel@daenzer.net 2010-07-14 04:22:20 PDT --- Created an attachment (id=37035) View: https://bugs.freedesktop.org/attachment.cgi?id=37035 Review: https://bugs.freedesktop.org/review?bug=28341&attachment=37035

Revert xf86-video-ati commit 30591320ec46e491ba20904cc64f3405b51c6505

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

--- Comment #14 from Andy Furniss lists@andyfurniss.entadsl.com 2010-07-16 06:02:09 PDT --- (In reply to comment #13)

(In reply to comment #12)

...

Created an attachment (id=37035)

View: https://bugs.freedesktop.org/attachment.cgi?id=37035 Review: https://bugs.freedesktop.org/review?bug=28341&attachment=37035

...

Revert xf86-video-ati commit 30591320ec46e491ba20904cc64f3405b51c6505

That fixes my two test cases - ipers and sauerbraten.

I see that with today's mesa master another workaround is possible.

vblank_mode=0 as an env (~/.drirc doesn't work for me) when running my test cases will fix the issue without the patch.

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

--- Comment #16 from Jerome Glisse glisse@freedesktop.org 2010-07-22 10:00:00 PDT --- Created an attachment (id=37317) View: https://bugs.freedesktop.org/attachment.cgi?id=37317 Review: https://bugs.freedesktop.org/review?bug=28341&attachment=37317

Add flush,invalidate on swap with msc

Please try if attached patch fix the issue for you (apply against mesa no change needed in ddx)

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

--- Comment #18 from Mario Kleiner mario.kleiner@tuebingen.mpg.de 2010-07-22 13:23:07 PDT --- Jerome,

as far as i can see, your flush, invalidate patch is in the right direction, but the dri2InvalidateDrawable() call just increments drawable->dri2.stamp and the current radeon dri driver in current mesa isn't checking the drawable->dri2.stamp for changes.

The intel driver has checks like...

if (drawable->lastStamp != drawable->dri2.stamp) intel_update_renderbuffers(driContext, drawable);

... in various places. Similar checks and calls to radeon_update_renderbuffers() would probably do the trick, because that would call DRI2GetBuffersWithFormat() etc. which will throttle properly until a swap is completed.

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

--- Comment #20 from Mario Kleiner mario.kleiner@tuebingen.mpg.de 2010-07-25 08:26:41 PDT --- Created an attachment (id=37368) View: https://bugs.freedesktop.org/attachment.cgi?id=37368 Review: https://bugs.freedesktop.org/review?bug=28341&attachment=37368

Proof of concept "fix" for R600/R700. Act on dri2InvalidateDrawable().

This patch together with the previous patch applied to current mesa git master eliminates the flicker problem on my tested apps with a R600 card.

A new function radeon_prepare_render() checks the timestamps that get updated by dri2InvalidateDrawable() to find out if a swap is in progress / buffers are invalidated. If so, it uses radeon_update_buffers() to get "new" buffers. That function will also throttle the client if a swap is still in progress. We'd need to add a call to radeon_prepare_render() to various places in the driver. This is what the intel driver does with intel_prepare_render() to avoid artifacts.

I've only added a check to r700DrawPrims() to see if it works at all. I don't know at which other locations such calls would be needed (and i'm a bloody beginner), so this is a pretty sketchy start.

-mario

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

Jerome Glisse glisse@freedesktop.org changed:

What |Removed |Added ---------------------------------------------------------------------------- Attachment #37366|0 |1 is obsolete| | Attachment #37368|0 |1 is obsolete| |

--- Comment #22 from Jerome Glisse glisse@freedesktop.org 2010-07-26 12:26:20 PDT --- Created an attachment (id=37401) View: https://bugs.freedesktop.org/attachment.cgi?id=37401 Review: https://bugs.freedesktop.org/review?bug=28341&attachment=37401

Fix dri2 swap

Can you confirm that the attach patch fix the issue for you (i have tested it on r200,r300,r600 and it seems to work UMS/KMS while also fixing what i believe is the issue you reported on KMS+DRI2)

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

--- Comment #24 from Mario Kleiner mario.kleiner@tuebingen.mpg.de 2010-07-26 17:31:53 PDT --- Jerome,

your Improved patch works on R600 for me as well, thanks for improving it and teaching me about the proper draw functions for non-r600 gpu's :-). It took me half a day to initially find r700DrawPrim() as the proper location for R600.

Looking at the code and comparing with the intel driver i think we should also add a radeon_prepare_render() to radeonReadPixels() in radeon_pixel_read.c, and the "copy from colorbuffer" path inside do_copy_texsubimage() in radeon_tex_copy.c ? Reading/Copying from the backbuffer/frontbuffer must also make sure it operates on the post-swap buffers, therefore wait for swap completion.

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

--- Comment #26 from Andy Furniss lists@andyfurniss.entadsl.com 2010-07-27 06:47:43 PDT --- (In reply to comment #25)

(In reply to comment #22)

...

Created an attachment (id=37401)

View: https://bugs.freedesktop.org/attachment.cgi?id=37401 Review: https://bugs.freedesktop.org/review?bug=28341&attachment=37401

...

Fix dri2 swap

Can you confirm that the attach patch fix the issue for you (i have tested it on r200,r300,r600 and it seems to work UMS/KMS while also fixing what i believe is the issue you reported on KMS+DRI2)

It fixes my test cases (ipers and sauerbraten) testing with rv770.

I've found a regression caused by the patch, the mesa demo singlebuffer segfaults.

singlebuffer[11119]: segfault at bf634ff0 ip b77e2b97 sp bf634fd0 error 6 in libGL.so.1.2[b77a7000+4e000]

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

--- Comment #28 from Andy Furniss lists@andyfurniss.entadsl.com 2010-07-27 11:30:10 PDT --- (In reply to comment #27)

Created an attachment (id=37414)

View: https://bugs.freedesktop.org/attachment.cgi?id=37414 Review: https://bugs.freedesktop.org/review?bug=28341&attachment=37414

Fix frontbuffer rendering, avoid segfault in singlebuffer demo.

This patch on top of the other patch works for me

Also fixes for me.

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

Mario Kleiner mario.kleiner@tuebingen.mpg.de changed:

What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED

--- Comment #30 from Mario Kleiner mario.kleiner@tuebingen.mpg.de 2010-08-02 12:11:45 PDT --- Patch with fix now in mesa master. Closing as resolved.