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. >> 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? >> >> [1] https://bugs.freedesktop.org/show_bug.cgi?id=32285 >> >> -- >> o...@lunarg.com >> _______________________________________________ >> mesa-dev mailing list >> mesa-dev@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/mesa-dev > >
-- o...@lunarg.com _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
