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

[Chia-I Wu]

2010/12/13 Kristian Høgsberg <krh at bitplanet.net>:
> On Sun, Dec 12, 2010 at 12: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.
>
> I really don't think this is something we should go out of our way to
> support.  It's broken by design, and even if we could fix it with
> library tricks, it's not something any GLES2/GL application could
> depend on, since it would be Mesa specific. And if we do some kind of
> hack to make this work, I don't want libGLESv2 ending up depending on
> libGL.so and all the X dependencies in there.  Better to have a shared
> glapi-only type library and then put GLX in a library that links to
> that and make libGLESv2 just a symlink to that.  But again, even if we
> do that, linking to both libGL and libGLESv2 isn't going to be widely
> supported, so GL applications and libraries will have to come up with
> their own workarounds anyway or use something like
>
>     https://blueprints.launchpad.net/linaro-graphics-wg/+spec/multimedia-linaro-runtime-gl-proxy
>
> I suppose there's no harm in adding this to mesa, but I don't see it
> solving the problem.
Mesa provides libGL.so, libGLESv1_CM.so, and libGLESv2.so.  And the
issue here is about applications linking to more than one of these
libraries, not just between libGL.so and libGLESv2.so.

While I am not aware of other stacks that provide both libGL.so and
libGLESv2.so, many mobile devices do provide both libGLESv1_CM.so and
libGLESv2.so.  Do linking to both libraries just work?  At least it is
a yes on devices based on Android

  http://git.android-x86.org/?p=platform/frameworks/base.git;a=tree;f=opengl/libs

But it is a NO for Mesa's libGLESv1_CM.so and libGLESv2.so.  Even
though this multiple shared libraries idea may be broken by design, it
is implied by EGL and vendors support it sanely.  I don't think this
change does not solve the problem.
>
> Kristian
>



-- 
olv at LunarG.com