Merging aiglx

[Ian Romanick]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Keith Whitwell wrote:
> Adam Jackson wrote:
> 
>> The pbuffer issue is that they can be shared between direct and
>> indirect contexts.  This is much easier to accomplish when only one
>> driver core is involved (like we have now with aiglx), but still
>> requires different instances of the driver to know how to find them
>> (was re: man we need a memory manager).  A pbuffer implementation that
>> clobbers the pbuffer every time it's touched is perfectly legal,
>> albeit useless, so that's certainly one possibility for the short term.
> 
> I'd been wondering about cases where direct and indirect contexts would
> have to use the same buffers (beyond the shared front buffer).  Looks
> like pbuffers is the requirement that will drive that.

I've been thinking about this a lot lately.  I think that we need some
way for a DRI driver to detect

a) I'm the only driver active in the system right now (e.g., server-side
AIGLX driver, EGL w/o X, etc.).

b) I know how to communicate buffer locations with all the other drivers
active in the system right now.

If either a) or b) is true, then the driver exports pbuffer fbconfigs.
If both are false, it does not.

For a long time I thought that AIGLX was going to be the pbuffers silver
bullet.  However, you can still have a case where the client-side driver
is (much) newer than the server-side driver, and the two are mutually
incompatible WRT pbuffers.

> The memory manager as it stands has "in principle" support for this sort
> of sharing, but there's definitely work to be done to get it right.  We
> probably won't tackle this immediately but if the GLX support is in
> place, proper pbuffer support won't be that huge of an effort now.

There are two things missing.

1. The protocol isn't implemented on the server-side.  This should be
trivial to wire up.  The code is already in place on the client-side
(see src/glx/x11/glx_pbuffer.c).

2. There are no entry-points into the DRI drivers for pbuffer functions.
 This shouldn't be too difficult, but it should be done with careful
forethought.  I don't think we will want to re-design it in another 6
months.  It looks like just GetDrawableAttribute and
ChangeDrawableAttribute are completely missing.  Most of the other
functions in glx_pbuffer.c just need to be wired into the existing entry
points and the entry points need to be updated to support pbuffers.

>> The rest of the protocol is well specified by now, and shouldn't be
>> particularly tough to wire up if we're not already there.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (GNU/Linux)

iD8DBQFEGaftX1gOwKyEAw8RAuY4AJ0UytGvm/GLfoGzqiFmfLkWlP3uIACgl2Zw
NMY3JNBmDlFXG6Nj051GJmg=
=/uAH
-----END PGP SIGNATURE-----