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

[Chia-I Wu]

2010/12/14 Chia-I Wu <olvaffe at gmail.com>:
> 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
Wrong link.  Here is the correct one
  http://android.git.kernel.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
>



-- 
olv at LunarG.com