2010/12/13 Kristian Høgsberg <k...@bitplanet.net>: > On Sun, Dec 12, 2010 at 12:45 PM, Chia-I Wu <olva...@gmail.com> wrote: >> On Fri, Dec 10, 2010 at 7:03 PM, Chia-I Wu <olva...@gmail.com> wrote: >>> On Fri, Dec 10, 2010 at 4:01 PM, Jammy Zhou <jammy.z...@linaro.org> wrote: >>>> On Fri, Dec 10, 2010 at 3:13 PM, Chia-I Wu <olva...@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 > -- o...@lunarg.com _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
