[Mesa-dev] DRI2 pixmap swapping
ajax at redhat.com
Wed Dec 7 08:55:14 PST 2011
On 12/7/11 4:16 AM, Michel Dänzer wrote:
> On Mit, 2011-12-07 at 08:40 +0000, Dave Airlie wrote:
>>> I have a feeling, since dri2 is not strictly restricted to GLX, whether this
>>> should really be
>>> implemented in the glx code before calling into dri2? Otoh that would mean
>>> the server side
>>> would need to be able to handle the case anyway.
>> The problem is that GLX doesn't get a chance, since the only place GLX
>> knows whether the drawable is window or pixmap is in the server, and
>> DRI2 protocol bypasses GLX to do this.
>> So I'm not really sure how we can block that.
> The client-side GLX code currently can't tell apart pixmaps from
> windows, but is there no way it could?
Implementing this I think either is fundamentally racy or requires new
API in libX11.
You can't track XIDs. You can't guarantee that all the GLXDrawables
you'll be asked to operate on are XIDs you libGL's self created, because
XIDs are global and some other app might have created it. You can't
even cache XIDs because there's no internal callbacks for "a client lib
sent an XID deletion request", and besides, some other process could
have destroyed it too.
So you have to check the drawable type right as you're about to use it.
The only way to do that is to round trip to the server (twice if
you're not using xcb), once for GetGeometry to see if it's a drawable
and then once for GetWindowAttributes to see if it's a pixmap.
That races, because between you getting the reply and you issuing your
next request, some other client can delete the resource, and in
principle even create a new one with the same XID but different type
. The only way to solve this would be to take a server grab around
the whole thing to keep XIDs still. But neither in the protocol nor in
xlib are grabs refcounted, so you can't "push" a grab.
You could fix this by requiring everyone to upgrade their libX11.
Having fixed it this way you'd now have slowed down SwapBuffers by a
round trip. No thanks.
 - This sounds unlikely if you think about the XID allocator
increasing only monotonically and wrapping at the very end of the range,
but I have a suspicion that the way xserver implements XC-MISC makes it
start aggressively reusing blocks from the _bottom_ of the XID space.
More information about the mesa-dev