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<http://cgit.freedesktop.org/%7Eolv/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'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.
> I suppose there's no harm in adding this to mesa, but I don't see it > solving the problem. > > Kristian > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev >
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
