<div class="gmail_quote">2010/12/13 Kristian Høgsberg <<a href="mailto:krh@bitplanet.net">krh@bitplanet.net</a>> <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div><div></div><div class="h5">On Sun, Dec 12, 2010 at 12:45 PM, Chia-I Wu <<a href="mailto:olvaffe@gmail.com">olvaffe@gmail.com</a>> wrote: > On Fri, Dec 10, 2010 at 7:03 PM, Chia-I Wu <<a href="mailto:olvaffe@gmail.com">olvaffe@gmail.com</a>> wrote: >> On Fri, Dec 10, 2010 at 4:01 PM, Jammy Zhou <<a href="mailto:jammy.zhou@linaro.org">jammy.zhou@linaro.org</a>> wrote: >>> On Fri, Dec 10, 2010 at 3:13 PM, Chia-I Wu <<a href="mailto:olvaffe@gmail.com">olvaffe@gmail.com</a>> 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 > > <a href="http://cgit.freedesktop.org/%7Eolv/mesa/log/?h=esapi-rework" target="_blank">http://cgit.freedesktop.org/~olv/mesa/log/?h=esapi-rework</a> > > Only the last commit is user-visible. It modifies <a href="http://configure.ac" target="_blank">configure.ac</a> 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. </div></div>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 <a href="https://blueprints.launchpad.net/linaro-graphics-wg/+spec/multimedia-linaro-runtime-gl-proxy" target="_blank">https://blueprints.launchpad.net/linaro-graphics-wg/+spec/multimedia-linaro-runtime-gl-proxy</a> </blockquote><div> 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. </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> I suppose there's no harm in adding this to mesa, but I don't see it solving the problem. Kristian <div><div></div><div class="h5">_______________________________________________ mesa-dev mailing list <a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/mesa-dev" target="_blank">http://lists.freedesktop.org/mailman/listinfo/mesa-dev</a> </div></div></blockquote></div>