2010/12/14 Chia-I Wu <olva...@gmail.com>: > 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 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 >> > > > > -- > o...@lunarg.com >
-- o...@lunarg.com _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
