On Tue, 2009-03-24 at 16:31 -0700, Eric Anholt wrote:
> On Tue, 2009-03-24 at 17:53 +0100, Michel Dänzer wrote:
> > Eric,
> >
> >
> > your mesa commit dd1c68f15123a889a3ce9d2afe724e272d163e32 ('dri2: Avoid
> > round-tripping on DRI2GetBuffers for the same set of buffers.') breaks
> > when the display connection doesn't receive ConfigureNotify events. This
> > can be reproduced by running a 3D application in a guest operating
> > system in VMware Workstation, which calls
> >
> > XSelectInput(..., ExposureMask);
> >
> > on the child window used for GL rendering. The GL driver ends up using
> > stale buffers / window size, so the output is cropped and misplaced.
> >
> > I wrote up the attached patch to fix this by adding StructureNotifyMask
> > to the event mask of the DRI2 display connection; this fixes the problem
> > above, but on second thought I'm concerned about potential side effects
> > of this approach on display connections which are otherwise not
> > interested in ConfigureNotify events. If I'm reading the libX11 event
> > queue management code correctly, this could result in an unlimited
> > number of ConfigureNotify events queueing up on the client side. In
> > practice the number may usually be low, but there could be more subtle
> > side effects, e.g. because the queue would not empty up anymore.
> >
> > So for Mesa 7.4, I suspect the safest course of action is to revert
> > dd1c68f15123a889a3ce9d2afe724e272d163e32. Something like the change
> > below could be used to at least limit the number of additional X server
> > round-trips to one per frame.
> >
> > What do you think?
>
> While I actually did the typing, the plan there (in particular the
> understanding of the event code) came mostly from Keith. I've added him
> to the Cc. Keith -- does this match your understanding of the event
> code?
>
> Ack on reverting the patch for 7.4, though if it's really not going to
> work out I'd rather revert it from master as well.
Sure, the plan is to cherry-pick whatever we end up doing on master to
the 7.4 branch.
> We can work around the cost by suppressing the getbuffers for internal
> glViewport calls (it was the plan before he came up with the clever
> hack).
I'm not sure that's necessary; the patch I included limits the number of
GetBuffers round-trips to one per frame regardless of where they were
triggered from. Do you or anyone see any problem with this?
OTOH I think the driver wouldn't need to update the buffers from
MakeCurrent.
--
Earthling Michel Dänzer | http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Mesa3d-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
