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

[Jakob Bornecrantz]

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
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).

Taking a step further back, does any vendor support OpenGL and GLES in
the same process?

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.

>>>> 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
>