Re: [Mesa-dev] [RFC] Solution to libGL.so and libGLES*.so mess
On Sun, Jan 16, 2011 at 10:42 AM, Chia-I Wu olva...@gmail.com wrote: On Fri, Dec 31, 2010 at 5:38 PM, Chia-I Wu olva...@gmail.com wrote: On Wed, Dec 29, 2010 at 3:50 AM, Chia-I Wu olva...@gmail.com wrote: Since the same-dispatch-offset-different-glx-opcodes functions are defined in GLX, glXGetProcAddress should be a better place to handle them specially than _glapi_get_proc_address is. With that change, I am quite happy with the current status of shared glapi http://cgit.freedesktop.org/~olv/mesa/log/?h=shared-glapi-2 I've created a diagram showing the differences between GLX and EGL in terms of libraries, and showing where libglapi is used http://people.freedesktop.org/~olv/tmp/egl-current.png (the image size exceeds the list limit) The diagram shows a default setup. When --enable-shared-glapi is given, libGL no longer defines _glapi* and libglapi will be used exclusively. It has been a while. If there is no objection, I will push the changes to master on Wednesday. I'm sorry that I didn't bring this up earlier but it would be theoretically possible with EGL to make GLES and Desktop GL current at the same time using dlopen and symbol mangling. const char* (*dglGetString)(GLenum); const char* (*glesGetString)(GLenum); eglMakeCurrent(gles_ctx, draw1, draw1); eglMakeCurrent(dgl_ctx, draw2, draw2); printf(%s, dglGetString(GL_VERSION)); printf(%s, glesGetString(GL_VERSION)); The above should be allowed since the spec says: If the calling thread already has a current context of the same client API type as ctx, then that context is flushed and marked as no longer current. and that OpenGLES and Desktop GL have different API types. But since your changes there can only be one current of any GL type. Cheers Jakob. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] Solution to libGL.so and libGLES*.so mess
On Thu, Jan 20, 2011 at 11:06 PM, Jakob Bornecrantz wallbra...@gmail.com wrote: On Sun, Jan 16, 2011 at 10:42 AM, Chia-I Wu olva...@gmail.com wrote: On Fri, Dec 31, 2010 at 5:38 PM, Chia-I Wu olva...@gmail.com wrote: On Wed, Dec 29, 2010 at 3:50 AM, Chia-I Wu olva...@gmail.com wrote: Since the same-dispatch-offset-different-glx-opcodes functions are defined in GLX, glXGetProcAddress should be a better place to handle them specially than _glapi_get_proc_address is. With that change, I am quite happy with the current status of shared glapi http://cgit.freedesktop.org/~olv/mesa/log/?h=shared-glapi-2 I've created a diagram showing the differences between GLX and EGL in terms of libraries, and showing where libglapi is used http://people.freedesktop.org/~olv/tmp/egl-current.png (the image size exceeds the list limit) The diagram shows a default setup. When --enable-shared-glapi is given, libGL no longer defines _glapi* and libglapi will be used exclusively. It has been a while. If there is no objection, I will push the changes to master on Wednesday. I'm sorry that I didn't bring this up earlier but it would be theoretically possible with EGL to make GLES and Desktop GL current at the same time using dlopen and symbol mangling. const char* (*dglGetString)(GLenum); const char* (*glesGetString)(GLenum); eglMakeCurrent(gles_ctx, draw1, draw1); eglMakeCurrent(dgl_ctx, draw2, draw2); printf(%s, dglGetString(GL_VERSION)); printf(%s, glesGetString(GL_VERSION)); The above should be allowed since the spec says: If the calling thread already has a current context of the same client API type as ctx, then that context is flushed and marked as no longer current. and that OpenGLES and Desktop GL have different API types. But since your changes there can only be one current of any GL type. This is the correct behavior. Near the beginning of section 3.7, Only one OpenGL or OpenGL ES context may be current to a particular thread, even if the implementation supports OpenGL and both OpenGL ES 1.x and OpenGL ES 2.x in the same runtime. Cheers Jakob. -- o...@lunarg.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] Solution to libGL.so and libGLES*.so mess
On Fri, Dec 31, 2010 at 5:38 PM, Chia-I Wu olva...@gmail.com wrote: On Wed, Dec 29, 2010 at 3:50 AM, Chia-I Wu olva...@gmail.com wrote: Since the same-dispatch-offset-different-glx-opcodes functions are defined in GLX, glXGetProcAddress should be a better place to handle them specially than _glapi_get_proc_address is. With that change, I am quite happy with the current status of shared glapi http://cgit.freedesktop.org/~olv/mesa/log/?h=shared-glapi-2 I've created a diagram showing the differences between GLX and EGL in terms of libraries, and showing where libglapi is used http://people.freedesktop.org/~olv/tmp/egl-current.png (the image size exceeds the list limit) The diagram shows a default setup. When --enable-shared-glapi is given, libGL no longer defines _glapi* and libglapi will be used exclusively. It has been a while. If there is no objection, I will push the changes to master on Wednesday. From a user's point of view, this branch brings two changes (implemented by the last two commits respectively). First, OpenGL ES 1.1 and 2.0 interop is fixed. There is now libglapi that is installed and shared by libGLESv1_CM and libGLESv2. The new libglapi has a stable API/ABI as described by glapi.h. The stability is to allow DRI drivers to be loaded as before. No external user of libglapi is expected. Then there is a new configure option, --enable-shared-glapi, which says that libGL should use the shared libglapi instead of defining its own copy. When enabled, it fixes OpenGL and OpenGL ES interop. This option is by default disabled as it is not needed for systems without OpenGL ES. When disabled, libGL is exactly the same as before. From a packager's point of view, libGLESv1_CM and libGLESv2 should be considered wrappers of libglapi. They must be created from the same source tree as libglapi is. The reason for this is that the dispatch offsets are re-assigned whenever GLAPI XMLs are changed. Similarly, when --enable-shared-glapi is specified, libGL is also considered a wrapper of libglapi. I would hope that --enable-shared-glapi is enabled everywhere and is eventually removed. But before that happens, it may be desirable to have libGL export no more than OpenGL 1.2 plus GL_ARB_multitexture functions. These are the functions defined by OpenGL ABI for Linux and that have fixed dispatch offsets. With that, libGL and libglapi need not have to be from the same source tree. -- o...@lunarg.com -- o...@lunarg.com -- o...@lunarg.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] Solution to libGL.so and libGLES*.so mess
The diagram looks sensible to me FWIW. But I'd like to point out though that spite the emergence of pipe_xxx.so and st_xxx.so dynamic drivers, the Gallium interface should remain a private interface of Mesa project. There is a lot of catching up necessary to support newer GL extensions and other Khronos APIs, so gallium interface will continue to evolve in the foreseeable future. Applications, toolkits, etc, should target GL/VG/CL/etc, for which there is a well established ABI defined. Jose From: mesa-dev-bounces+jfonseca=vmware@lists.freedesktop.org [mesa-dev-bounces+jfonseca=vmware@lists.freedesktop.org] On Behalf Of Chia-I Wu [olva...@gmail.com] Sent: Sunday, January 16, 2011 9:42 To: mesa-dev@lists.freedesktop.org Subject: Re: [Mesa-dev] [RFC] Solution to libGL.so and libGLES*.so mess On Fri, Dec 31, 2010 at 5:38 PM, Chia-I Wu olva...@gmail.com wrote: On Wed, Dec 29, 2010 at 3:50 AM, Chia-I Wu olva...@gmail.com wrote: Since the same-dispatch-offset-different-glx-opcodes functions are defined in GLX, glXGetProcAddress should be a better place to handle them specially than _glapi_get_proc_address is. With that change, I am quite happy with the current status of shared glapi http://cgit.freedesktop.org/~olv/mesa/log/?h=shared-glapi-2 I've created a diagram showing the differences between GLX and EGL in terms of libraries, and showing where libglapi is used http://people.freedesktop.org/~olv/tmp/egl-current.png (the image size exceeds the list limit) The diagram shows a default setup. When --enable-shared-glapi is given, libGL no longer defines _glapi* and libglapi will be used exclusively. It has been a while. If there is no objection, I will push the changes to master on Wednesday. From a user's point of view, this branch brings two changes (implemented by the last two commits respectively). First, OpenGL ES 1.1 and 2.0 interop is fixed. There is now libglapi that is installed and shared by libGLESv1_CM and libGLESv2. The new libglapi has a stable API/ABI as described by glapi.h. The stability is to allow DRI drivers to be loaded as before. No external user of libglapi is expected. Then there is a new configure option, --enable-shared-glapi, which says that libGL should use the shared libglapi instead of defining its own copy. When enabled, it fixes OpenGL and OpenGL ES interop. This option is by default disabled as it is not needed for systems without OpenGL ES. When disabled, libGL is exactly the same as before. From a packager's point of view, libGLESv1_CM and libGLESv2 should be considered wrappers of libglapi. They must be created from the same source tree as libglapi is. The reason for this is that the dispatch offsets are re-assigned whenever GLAPI XMLs are changed. Similarly, when --enable-shared-glapi is specified, libGL is also considered a wrapper of libglapi. I would hope that --enable-shared-glapi is enabled everywhere and is eventually removed. But before that happens, it may be desirable to have libGL export no more than OpenGL 1.2 plus GL_ARB_multitexture functions. These are the functions defined by OpenGL ABI for Linux and that have fixed dispatch offsets. With that, libGL and libglapi need not have to be from the same source tree. -- o...@lunarg.com -- 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
Re: [Mesa-dev] [RFC] Solution to libGL.so and libGLES*.so mess
On Sun, Jan 16, 2011 at 9:25 PM, Jose Fonseca jfons...@vmware.com wrote: The diagram looks sensible to me FWIW. Great. But I'd like to point out though that spite the emergence of pipe_xxx.so and st_xxx.so dynamic drivers, the Gallium interface should remain a private interface of Mesa project. There is a lot of catching up necessary to support newer GL extensions and other Khronos APIs, so gallium interface will continue to evolve in the foreseeable future. Applications, toolkits, etc, should target GL/VG/CL/etc, for which there is a well established ABI defined. Yes. They (pipe_xxx.so and st_xxx.so) are private modules to egl_gallium.so. No stable ABI is guaranteed between them. Packagers usually package them together wit egl_gallium in a separate package. Despite that, they and egl_gallium should theoretically not be installed when there are DRI drivers and egl_dri2. egl_gallium is more for special needs on such systems, such as EGL/fbdev and OSMESA-like substitute. And for those needs, egl_gallium can be made a built-in driver of libEGL, meaning no egl_gallium.so, no pipe_xxx.so, and no st_xxx.so. It is however installed to supplement egl_dri2 in some situations: swrast, openvg, and nouveau. (Nothing stops egl_dri2 from doing those except that the code is not written) Jose From: mesa-dev-bounces+jfonseca=vmware@lists.freedesktop.org [mesa-dev-bounces+jfonseca=vmware@lists.freedesktop.org] On Behalf Of Chia-I Wu [olva...@gmail.com] Sent: Sunday, January 16, 2011 9:42 To: mesa-dev@lists.freedesktop.org Subject: Re: [Mesa-dev] [RFC] Solution to libGL.so and libGLES*.so mess On Fri, Dec 31, 2010 at 5:38 PM, Chia-I Wu olva...@gmail.com wrote: On Wed, Dec 29, 2010 at 3:50 AM, Chia-I Wu olva...@gmail.com wrote: Since the same-dispatch-offset-different-glx-opcodes functions are defined in GLX, glXGetProcAddress should be a better place to handle them specially than _glapi_get_proc_address is. With that change, I am quite happy with the current status of shared glapi http://cgit.freedesktop.org/~olv/mesa/log/?h=shared-glapi-2 I've created a diagram showing the differences between GLX and EGL in terms of libraries, and showing where libglapi is used http://people.freedesktop.org/~olv/tmp/egl-current.png (the image size exceeds the list limit) The diagram shows a default setup. When --enable-shared-glapi is given, libGL no longer defines _glapi* and libglapi will be used exclusively. It has been a while. If there is no objection, I will push the changes to master on Wednesday. From a user's point of view, this branch brings two changes (implemented by the last two commits respectively). First, OpenGL ES 1.1 and 2.0 interop is fixed. There is now libglapi that is installed and shared by libGLESv1_CM and libGLESv2. The new libglapi has a stable API/ABI as described by glapi.h. The stability is to allow DRI drivers to be loaded as before. No external user of libglapi is expected. Then there is a new configure option, --enable-shared-glapi, which says that libGL should use the shared libglapi instead of defining its own copy. When enabled, it fixes OpenGL and OpenGL ES interop. This option is by default disabled as it is not needed for systems without OpenGL ES. When disabled, libGL is exactly the same as before. From a packager's point of view, libGLESv1_CM and libGLESv2 should be considered wrappers of libglapi. They must be created from the same source tree as libglapi is. The reason for this is that the dispatch offsets are re-assigned whenever GLAPI XMLs are changed. Similarly, when --enable-shared-glapi is specified, libGL is also considered a wrapper of libglapi. I would hope that --enable-shared-glapi is enabled everywhere and is eventually removed. But before that happens, it may be desirable to have libGL export no more than OpenGL 1.2 plus GL_ARB_multitexture functions. These are the functions defined by OpenGL ABI for Linux and that have fixed dispatch offsets. With that, libGL and libglapi need not have to be from the same source tree. -- o...@lunarg.com -- o...@lunarg.com -- 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
Re: [Mesa-dev] [RFC] Solution to libGL.so and libGLES*.so mess
On Wed, Dec 29, 2010 at 3:50 AM, Chia-I Wu olva...@gmail.com wrote: Since the same-dispatch-offset-different-glx-opcodes functions are defined in GLX, glXGetProcAddress should be a better place to handle them specially than _glapi_get_proc_address is. With that change, I am quite happy with the current status of shared glapi http://cgit.freedesktop.org/~olv/mesa/log/?h=shared-glapi-2 I've created a diagram showing the differences between GLX and EGL in terms of libraries, and showing where libglapi is used http://people.freedesktop.org/~olv/tmp/egl-current.png (the image size exceeds the list limit) The diagram shows a default setup. When --enable-shared-glapi is given, libGL no longer defines _glapi* and libglapi will be used exclusively. From a user's point of view, this branch brings two changes (implemented by the last two commits respectively). First, OpenGL ES 1.1 and 2.0 interop is fixed. There is now libglapi that is installed and shared by libGLESv1_CM and libGLESv2. The new libglapi has a stable API/ABI as described by glapi.h. The stability is to allow DRI drivers to be loaded as before. No external user of libglapi is expected. Then there is a new configure option, --enable-shared-glapi, which says that libGL should use the shared libglapi instead of defining its own copy. When enabled, it fixes OpenGL and OpenGL ES interop. This option is by default disabled as it is not needed for systems without OpenGL ES. When disabled, libGL is exactly the same as before. From a packager's point of view, libGLESv1_CM and libGLESv2 should be considered wrappers of libglapi. They must be created from the same source tree as libglapi is. The reason for this is that the dispatch offsets are re-assigned whenever GLAPI XMLs are changed. Similarly, when --enable-shared-glapi is specified, libGL is also considered a wrapper of libglapi. I would hope that --enable-shared-glapi is enabled everywhere and is eventually removed. But before that happens, it may be desirable to have libGL export no more than OpenGL 1.2 plus GL_ARB_multitexture functions. These are the functions defined by OpenGL ABI for Linux and that have fixed dispatch offsets. With that, libGL and libglapi need not have to be from the same source tree. -- o...@lunarg.com -- o...@lunarg.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] Solution to libGL.so and libGLES*.so mess
On Mon, Dec 13, 2010 at 12:51 PM, Jakob Bornecrantz wallbra...@gmail.com wrote: 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 There will still be two copies of _glapi_* in the process's memory, including two copies of _glapi_Dispatch (global variable). There is no guarantee that _glapi_set_dispatch will set the one that mesa core uses. 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
Re: [Mesa-dev] [RFC] Solution to libGL.so and libGLES*.so mess
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. Kristian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] Solution to libGL.so and libGLES*.so mess
On Sun, Dec 12, 2010 at 7:19 PM, Jammy Zhou jammy.z...@linaro.org wrote: Hi Chia-I, Glad to see the fix goes so fast, thanks! I believe the direction is promising. And I am not familiar with the mapi module of mesa, so just one minor comment for the glapi: Fix OpenGL and OpenGL ES interop patch. For changes in configure.ac, please use \ instead of \', i.e, GLAPI_OWNER='$(GL_LIB)' - GLAPI_OWNER=$(GL_LIB). Sorry, but you do want single quotes here so that the variable doesn't get expanded until make does it. With double quotes, you'd be trying to run the shell function $(GL_LIB), which isn't a function. -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] Solution to libGL.so and libGLES*.so mess
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
Re: [Mesa-dev] [RFC] Solution to libGL.so and libGLES*.so mess
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 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
Re: [Mesa-dev] [RFC] Solution to libGL.so and libGLES*.so mess
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-reworkhttp://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
[Mesa-dev] [RFC] Solution to libGL.so and libGLES*.so mess
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. 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
Re: [Mesa-dev] [RFC] Solution to libGL.so and libGLES*.so mess
Hi Chia-I, Glad to see the fix goes so fast, thanks! I believe the direction is promising. And I am not familiar with the mapi module of mesa, so just one minor comment for the glapi: Fix OpenGL and OpenGL ES interop patch. For changes in configure.ac, please use \ instead of \', i.e, GLAPI_OWNER='$(GL_LIB)' - GLAPI_OWNER=$(GL_LIB). Regards, Jammy On Mon, Dec 13, 2010 at 1:45 AM, 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-reworkhttp://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. 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. 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
Re: [Mesa-dev] [RFC] Solution to libGL.so and libGLES*.so mess
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
Re: [Mesa-dev] [RFC] Solution to libGL.so and libGLES*.so mess
On Mon, Dec 13, 2010 at 4:19 AM, Jammy Zhou jammy.z...@linaro.org wrote: Hi Chia-I, Glad to see the fix goes so fast, thanks! I believe the direction is promising. Hijacking this thread a bit, can I ask why you need check the renderer string for both GL and GLES? Running GL and GLES in the same process is a not something you normally do. Cheers Jakob. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] Solution to libGL.so and libGLES*.so mess
On Mon, Dec 13, 2010 at 12:54 PM, Jakob Bornecrantz wallbra...@gmail.comwrote: On Mon, Dec 13, 2010 at 4:19 AM, Jammy Zhou jammy.z...@linaro.org wrote: Hi Chia-I, Glad to see the fix goes so fast, thanks! I believe the direction is promising. Hijacking this thread a bit, can I ask why you need check the renderer string for both GL and GLES? Running GL and GLES in the same process is a not something you normally do. I want to check the renderer string to see underlying GL and GLESv2 are hardware accelerated or not, and select a proper one at runtime as the rendering backend. Mesa GL and GLESv2 combination is one use case for my project. Cheers Jakob. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
