Merging aiglx

[Ian Romanick]

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

Kristian Høgsberg wrote:
> Hello,
> 
> It's been a couple of weeks since I posted my aiglx patch and there
> hasn't been a lot of feedback, so I'm going to go ahead and assume
> everybody is happy with the approach.  In the meantime, we've fixed a
> number of crashers, added better logging and added hooks to allow the
> GLXprovider to implement the GLX_EXT_tfp extension.
> 
> Unless there are any objections to this, I'll merge the aiglx branch to
> head this friday (yay, one less branch to keep in sync with mesa).

I do have a couple questions / comments about the code in the branch.  I
don't think that it's anything that should block merging the code to
HEAD, though.

1. Why is just glXGetDrawableAttributesSGIX implemented?

This function is part of GLX_SGIX_pbuffers (and glXGetDrawableAttributes
is part of GLX 1.3).  Without that extension being advertised by the
implementation, an application won't know it is available.  It should be
easy enough to add the other functions but not make any fbconfigs that
support pbuffers available.

2. Why is __GLXtextureFromPixmap a stand alone structure?

It seems like the two function pointers in __GLXtextureFromPixmap should
just be part of __GLXcontext.

3. DrawableGone is coded as though setting __GLX_PENDING_DESTROY may
automatically free the object.  Is that the case?  If so, there's a
problem when the same drawable is bound for both reading and drawing.

4. Any idea why __glXDispatch had a test for whether or not we were
expecting a follow-on RenderLarge request but __glXSwapDispatch did not?

In any case, I like it that those two functions were merged.
Refactoring like that makes me happy. :)

5. There's a (tivial) merge conflict in GL/mesa/swrast/Makefile.am.

6. I'd recommend caching whether or not a context can support
non-power-of-2 textures for GL_TEXTURE_2D in the GLXcontext structure.
I see that the code is commented out, but using GL_TEXTURE_2D, if
available, is the right way to go.  Since GL_TEXTURE_RECTANGLE_ARB uses
unnormalized coordinates (i.e., [0,width] vs. [0,1]), how is this handled?

7. How are GLX extensions handled?

On the client-side, the driver tells the loader which GLX extensions it
can support.  It appears that right now all of the extensions that have
GLX protocol supported are always advertised.  This is a problem as some
GLX extesions (e.g., SGI_make_current_read, GLX_SGIX_hyperpipe, and
GLX_SGIX_swap_barrier) are *not* supported by all DRI drivers.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFEEKM5X1gOwKyEAw8RAnD2AJ0SOqtQkb8S+i/WQ0vaCdXFkctmHgCglm6D
0BWTdchHg45iHHlT6P3TVTE=
=mhFv
-----END PGP SIGNATURE-----