glapi.c drift between Mesa and X server

Ian Romanick idr at
Wed Nov 11 13:47:48 PST 2009

Hash: SHA1

I need to fix a bug in the X server glapi.c (bugzilla #23335).
Traditionally, glx/glapi.c was just a copy of src/mesa/glapi/glapi.c.
It seems that Mesa's version has not been synchronized to the X server
in a long, long time.  It also seems that glx/glapi.c has received a few
commits that are not in Mesa.

It looks like the current version in Mesa contains code that won't even
compile in the X server.  At the very least, the include of
main/compiler.h needs to be moved.  A bunch of the code that used to be
in glapi.c was also recently moved to glapi_getproc.c.

How should I proceed?

 * Fix the bug in Mesa's copy of glapi.c (under some sort of #ifdef),
and sync it back to the X server.

 * Admit that we'll never keep these properly in sync, and just fix the
bug in the X server's copy.

I'm somewhat leaning towards the later.  Most of glapi.c and
glapi_getproc.c is completely unnecessary on the server.  The bulk of
the code deals with dynamic generation of dispatch stubs for extensions
exposed by the driver that are unknown to libGL.  Since everything on
the server comes through GLX protocol, there is no way to get to a
function that is unknown to the server.

When we add support 2D drivers calling into the 3D driver (i.e.,
glamor), I don't expect this to become an issue.  The 2D driver will
just call directly through the dispatch table in the same manner the GLX
protocol code does.

Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


More information about the xorg-devel mailing list