[Mesa-dev] [RFC] Solution to libGL.so and libGLES*.so mess
jammy.zhou at linaro.org
Sun Dec 12 19:19:34 PST 2010
Glad to see the fix goes so fast, thanks! I believe the direction is
promising. And I am not familiar with the mapi module of mesa, so just one
minor comment for the "glapi: Fix OpenGL and OpenGL ES interop" patch.
For changes in configure.ac, please use \" instead of \', i.e,
On Mon, Dec 13, 2010 at 1:45 AM, 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>
> >> 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. 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
> >> 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
> 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
> 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.
> >>> 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?
> >>>  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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mesa-dev