[Mesa3d-dev] glapi.c drift between Mesa and X server

[Brian Paul]

On Wed, Nov 11, 2009 at 2:47 PM, Ian Romanick <idr at freedesktop.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 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.
>
> Opinions?

Unless it's going to be really hard or messy, I'd prefer to keep the
code shared and in-sync.

Perhaps glapi.c needs to be split into some smaller pieces to make
sharing easier.

-Brian