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@xxxxxxxxxxxxxxx
> > Subject: [Bug 28341] Flickering screen in Neverball on
> > drm-radeon-testing
> > To: dri-devel@xxxxxxxxxxxxxxxxxxxxx
> > Message-ID: <20100601192542.ACE5B1300E8@xxxxxxxxxxxxxxxxxxxxxxxx>
> > Content-Type: text/plain; charset="UTF-8"
> >
> > https://bugs.freedesktop.org/show_bug.cgi?id=28341
> >
> > --- Comment #3 from Magnus Jensen <magnus@xxxxxxxxxxxxxx>
> > 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
diff --git a/src/glx/dri2_glx.c b/src/glx/dri2_glx.c
index 8a5aaa4..e0596be 100644
--- a/src/glx/dri2_glx.c
+++ b/src/glx/dri2_glx.c
@@ -457,6 +457,10 @@ dri2SwapBuffers(__GLXDRIdrawable *pdraw, int64_t target_msc, int64_t divisor,
#ifdef X_DRI2SwapBuffers
DRI2SwapBuffers(pdraw->psc->dpy, pdraw->xDrawable, target_msc, divisor,
remainder, &ret);
+
+ /* Make sure we call to the server before rendering again, in case we need
+ * to block for the swap */
+ dri2InvalidateBuffers(dpyPriv->dpy, pdraw->drawable);
#endif
return ret;
diff --git a/src/radeon_dri2.c b/src/radeon_dri2.c
index 0ecdcd4..304a61d 100644
--- a/src/radeon_dri2.c
+++ b/src/radeon_dri2.c
@@ -736,6 +736,7 @@ static int radeon_dri2_schedule_swap(ClientPtr client, DrawablePtr draw,
*target_msc = vbl.reply.sequence + flip;
swap_info->frame = *target_msc;
+ DRI2BlockClient(client, draw);
return TRUE;
blit_fallback:
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
