On Sun, Dec 12, 2010 at 6: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. > > Internally, the branch modifies es1api and es2api to use mapi-based > glapi.h implementation. This switch is made because in the most > common case where libGL.so is GLAPI_OWNER, es1api and es2api is quite > different from glapi. It is not easy for them to share the same code > base. On the other hand, mapi is mroe flexible to fullfil both needs. > > The change to glapi is that 3 new extensions are added: > GL_ARB_ES2_compatibility, GL_OES_single_precision, and > GL_OES_fixed_point. There is no intention to support these > extensions. They are added so that dispatch table offsets are > assigned to OpenGL ES 1.1 and 2.0 functions. These offsets are then > shared with libGLES*.so. An implication of this is libGL.so and > libGLES*.so must be built from the same gl_API.xml as any change to > gl_API.xml may alter the offsets assigned. > > This limitation can actually be lifted by assigning fixed dispatch > offsets to OpenGL ES 1.1 and 2.0 functions, as is done for OpenGL 1.2 > and GL_ARB_multitexture functions. But I am not sure if it is a good > idea to assign fixed dispatch offsets to OpenGL ES 1.1 and 2.0 > functions. It is thus left out in this branch.
If libGLES* actually depend on libGL isn't just better to just symlink libGLES to libGL and avoid a whole bunch of extra code? Or better yet use magical linux library magic, to create a wrapper library that only exposes the libGLES symbols but points to libGL (I don't know how, but this was brought up at XDS2010 by Adam Jackson when discussing xcb). Taking a step further back, does any vendor support OpenGL and GLES in the same process? On I sort of related note I be happy if the ES2 compatibility extension was implemented, as I think it would fix some of these issues. >>>> 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 >> > > > > -- > o...@lunarg.com > _______________________________________________ > 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
