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
