[Mesa-dev] [RFC] Solution to libGL.so and libGLES*.so mess

Chia-I Wu olvaffe at gmail.com
Sat Dec 18 03:02:48 PST 2010


I am back at this issue with a second try

  http://cgit.freedesktop.org/~olv/mesa/log/?h=shared-glapi

In a nutshell, this branch introduces a new configure option,
--enable-shared-glapi.  By default it is disabled and things work as
before.  But when it is enabled, all except one (more on this below)
_glapi_* symbols are removed from libGL.so, libGLESv1_CM.so, and
libGLESv2.so.  There is going to be libGLAPI.so that provides these
symbols, and these libraries simply link to the new library.  libGL.so
loads DRI drivers well with or without shared glapi.

Having a shared glapi fixes OpenGL, GLES 1.1, and GLES 2.0
interoperation, as is supported by other OpenGL ES stacks.

The one symbol that is not moved to libGLAPI.so is
_glapi_get_proc_address.  If you take a look at glapi on master, you
will notice that while libglapi.a provides _glapi_get_proc_address to
look up any OpenGL function recognized, not all of the functions are
defined by libglapi.a.  When functions are promoted from extension to
core, some of them, such as glGenTexturesEXT, are given different GLX
opcodes.  Since glGenTextures and glGenTexturesEXT have already been
assigned the same dispatch offset, to differentiate them, the latter
cannot be defined in libglapi.a.  It is instead defined in
src/glx/indirect.c.

When shared glapi is enabled, libGLAPI.so cannot correctly define
glGenTexturesEXT, nor can it support
_glapi_get_proc_address("glGenTexturesEXT").  The solution is for
libGLAPI.so to rename _glapi_get_proc_address and for the other
libraries to define their own versions of _glapi_get_proc_address.
This gives libGL.so a chance to properly support glGenTexturesEXT.
This mechanism is implemented by

  7a6370b mapi: Fix bridge mode fo GLX.

In my first try, there was no libGLAPI.so (_glapi_* still in libGL.so)
and libGLES* linked to libGL.so.  That was chose for this very reason.
 But that choice made libGLES* depend on libGL.so, which in turn
brought in X11 dependencies.  That was not considered a good move and
thus this second try with shared glapi opt-out.

-- 
olv at LunarG.com


More information about the mesa-dev mailing list