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

[Jose Fonseca]

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.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