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

[Jammy Zhou]

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<http://cgit.freedesktop.org/%7Eolv/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'm working on this GL proxy project. And the problem in this thread is
found when I tried to check the renderer info of OpenGL and OpenGL ES2.0
driver in one process to select proper backend automatically.


> I suppose there's no harm in adding this to mesa, but I don't see it
> solving the problem.
>
> Kristian
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20101214/4eb99630/attachment.htm>