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

Chia-I Wu olvaffe at gmail.com
Mon Dec 13 00:40:08 PST 2010


On Mon, Dec 13, 2010 at 12:51 PM, Jakob Bornecrantz
<wallbraker at gmail.com> wrote:
> On Sun, Dec 12, 2010 at 6:45 PM, Chia-I Wu <olvaffe at gmail.com> wrote:
>> On Fri, Dec 10, 2010 at 7:03 PM, Chia-I Wu <olvaffe at gmail.com> wrote:
>>> On Fri, Dec 10, 2010 at 4:01 PM, Jammy Zhou <jammy.zhou at linaro.org> wrote:
>>>> On Fri, Dec 10, 2010 at 3:13 PM, Chia-I Wu <olvaffe at gmail.com> wrote:
>>>>> With OpenGL ES coming to desktop, the way the current context/dispatch
>>>>> is stored, together with the way libGLES*.so is created, causes
>>>>> several issues[1].  The root of these issues is that the symbols
>>>>> defined in libGL.so and in libGLES*.so overlaps, and an application
>>>>> might link to both of them indirectly!
>>>>>
>>>>> In light of GLX_EXT_create_context_es2_profile, the simplest solution
>>>>> would be to stop distributing libGLES*.so.  Applications will always
>>>>> link to libGL.so.  Those that use GLX can then call glXGetProcAddress
>>>>> to get the addresses of OpenGL ES 2.0 functions.  But those that use
>>>>> EGL will be in trouble.  eglGetProcAddress is defined not to return
>>>>> the addresses of non-extension functions.
>>>>
>>>> I don't think it is a good solution to stop distributing libGLES*.so,
>>>> because in embeded/mobile world, a lot of applications have dependency on
>>>> libGLES*.so instead of libGL.so.
>>> I am curious how other vendors solve this issue.  Or more generally,
>>> how other toolkits solve providing mulitple shared libraries with
>>> overlapping symbols, and that are also supposed to be used altogether.
>>>>>
>>>>> If libGL.so and libGLES*.so both have to be distributed, then the
>>>>> question becomes how to handle symbols that overlaps gracefully.
>>>>>
>>>>> Accessing global variables such as _glapi_Context and _glapi_Dispatch
>>>>> will fail.  Say libGL.so and libGLES*.so both has a copy of
>>>>> _glapi_Context.  There is no guarantee that GET_CURRENT_CONTEXT will
>>>>> return the same context set by _glapi_set_context.
>>>>>
>>>>> Calling global functions will work as long as they are identical in
>>>>> both libGL.so and libGLES*.so.  This means both libraries must agree
>>>>> on the order of slots in the dispatch table.  And the problem with two
>>>>> copies of global _glapi_Dispatch also needs to be solved.
>>>>>
>>>>> One solution for these issues is to move _glapi_Context,
>>>>> _glapi_Dispatch, and _glapi_* functions to libglapi.so.  libGL.so and
>>>>> libGLES*.so will both link to libglapi.so.  All the libraries must be
>>>>> distributed together, as they must agree on the dispatch table used.
>>>>> This change should not break the ABI for existing DRI drivers.
>>> Or to pick one of the libraries to own libglapi, and have others link to it.
>> I've been working toward this direction.  libGL.so will provide
>> _glapi_* symbols as it is now.  libGLES*.so will depend on libGL.so
>> instead of providing another copy of _glapi_*.  On a x86 machine,
>> libGLESv1_CM.so and libGLESv2.so are down to 17K and 18K in size
>> respectively.  The work can be found at
>>
>>  http://cgit.freedesktop.org/~olv/mesa/log/?h=esapi-rework
>>
>> Only the last commit is user-visible.  It modifies configure.ac to
>> define GLAPI_OWNER, which is the library that owns _glapi_* symbols.
>> It is always $(GL_LIB) unless --disable-opengl is given.  When
>> libGLES*.so is built, Makefile will check if libGLES*.so is
>> GLAPI_OWNER and decide whether libGLES*.so should define _glapi_*
>> symbols itself, or use those from GLAPI_OWNER.
>>
>> Internally, the branch modifies es1api and es2api to use mapi-based
>> glapi.h implementation.  This switch is made because in the most
>> common case where libGL.so is GLAPI_OWNER, es1api and es2api is quite
>> different from glapi.  It is not easy for them to share the same code
>> base.  On the other hand, mapi is mroe flexible to fullfil both needs.
>>
>> The change to glapi is that 3 new extensions are added:
>> GL_ARB_ES2_compatibility, GL_OES_single_precision, and
>> GL_OES_fixed_point.  There is no intention to support these
>> extensions.  They are added so that dispatch table offsets are
>> assigned to OpenGL ES 1.1 and 2.0 functions.  These offsets are then
>> shared with libGLES*.so.  An implication of this is libGL.so and
>> libGLES*.so must be built from the same gl_API.xml as any change to
>> gl_API.xml may alter the offsets assigned.
>>
>> This limitation can actually be lifted by assigning fixed dispatch
>> offsets to OpenGL ES 1.1 and 2.0 functions, as is done for OpenGL 1.2
>> and GL_ARB_multitexture functions.  But I am not sure if it is a good
>> idea to assign fixed dispatch offsets to OpenGL ES 1.1 and 2.0
>> functions.  It is thus left out in this branch.
>
> If libGLES* actually depend on libGL isn't just better to just symlink libGLES
> to libGL and avoid a whole bunch of extra code? Or better yet use magical
There will still be two copies of _glapi_* in the process's memory,
including two copies of _glapi_Dispatch (global variable).  There is
no guarantee that _glapi_set_dispatch will set the one that mesa core
uses.
> linux library magic, to create a wrapper library that only exposes the libGLES
> symbols but points to libGL (I don't know how, but this was brought up at
> XDS2010 by Adam Jackson when discussing xcb).
That sounds like a solution.  Anyone familiar with that subject?
>
> Taking a step further back, does any vendor support OpenGL and GLES in
> the same process?
When an app uses a toolkit for the 2D part and use OpenGL ES for the
3D part, and when the toolkit actually uses OpenGL, there may be
problem.  cairo-gl or evas-gl are two such toolkits.

I did not investigate if any vendor supports OpenGL and GLES in one
process.  But mobile devices usually have to deal with GLES1 and GLES2
interop, which is the same issue.  IIRC, some of them have a third
shared library that libGLESv1_CM.so and libGLESv2.so link to.  It is
similar to this proposed solution, where libGL.so serves as the third
shared library.

> On I sort of related note I be happy if the ES2 compatibility extension was
> implemented, as I think it would fix some of these issues.
GL_ARB_ES2_compatibility or GLX_EXT_create_context_es2_profile is not
encumbered by this issue.  There is no libGLES*.so involved.
>>>>> Another option is make _glapi_Context and _glapi_Dispatch local.
>>>>> libGL.so, libGLES*.so, and every DRI driver will get a renamed local
>>>>> copy of _glapi_Context and _glapi_Dispatch.  To not break the ABI for
>>>>> old DRI drivers, libGL.so and libGLES*.so will still export
>>>>> _glapi_Dispatch and _glapi_Context.  But same as the first solution,
>>>>> there must be a big dispatch table that libGL.so and libGLES*.so can
>>>>> agree on.
>>> Sorry, this won't work.
>>>>> There should be other options, but these are all I have now.  Any
>>>>> thought?
>>>>>
>>>>> [1] https://bugs.freedesktop.org/show_bug.cgi?id=32285
>>>>>
>>>>> --
>>>>> olv at LunarG.com
>>>>> _______________________________________________
>>>>> mesa-dev mailing list
>>>>> mesa-dev at lists.freedesktop.org
>>>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> olv at LunarG.com
>>>
>>
>>
>>
>> --
>> olv at LunarG.com
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>>
>



-- 
olv at LunarG.com


More information about the mesa-dev mailing list