[Mesa-dev] [RFC] Solution to libGL.so and libGLES*.so mess

[Chia-I Wu]

On Sun, Jan 16, 2011 at 9:25 PM, Jose Fonseca <jfonseca at 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.com at lists.freedesktop.org [mesa-dev-bounces+jfonseca=vmware.com at lists.freedesktop.org] On Behalf Of Chia-I Wu [olvaffe at gmail.com]
> Sent: Sunday, January 16, 2011 9:42
> To: mesa-dev at 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 <olvaffe at gmail.com> wrote:
>> On Wed, Dec 29, 2010 at 3:50 AM, Chia-I Wu <olvaffe at 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.
>>>
>>> --
>>> olv at LunarG.com
>>>
>>
>>
>>
>> --
>> olv at LunarG.com
>>
>
>
>
> --
> olv at LunarG.com
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>



-- 
olv at LunarG.com