[Mesa-dev] [PATCH 00/11] glapi fixes - build whole of mesa with

[Emil Velikov]

On 19 June 2015 at 21:26, Jose Fonseca <jfonseca at vmware.com> wrote:
> On 19/06/15 20:56, Emil Velikov wrote:
>>
>> Hi all,
>>
>> A lovely series inspired (more like 'was awaken to send these out') by
>> Pal Rohár, who was having issues when building xlib-libgl (plus the now
>> enabled gles*)
>>
>> So here, we teach the final two static glapi users about shared-glapi,
>> plus some related fixes. After this is done we can finally start
>> transitioning to shared-only glapi, with some more details as mentioned
>> in one of the patches:
>>
>>      XXX: With this one done, we can finally transition with enforcing
>>      shared-glapi, and
>>
>>       - link the dri modules against libglapi.so, add --no-undefined to
>>      the LDFLAGS
>>       - drop the dlopen(libglapi.so/libGL.so, RTLD_GLOBAL) workarounds
>>      in the loaders - libGL, libEGL and libgbm.
>>       - start killing off/cleaning up the dispatch ?
>>
>>      The caveats:
>>      1) up to what stage do we care about static libraries
>>       - libgl (either dri or xlib based)
>>       - osmesa
>>       - libEGL
>>
>>      2) how about other platforms (scons) ?
>>       - currently the scons uses static glapi,
>>       - would we need the dlopen(...) on windows ?
>>
>> Hope everyone is excited about this one as I am :-)
>
>
> Maybe I missed the context of this changes, but why this matters or is an
> improvement?
>
If one goes the extra mile (which this series doesn't) - one configure
option less, substantial some code de-duplication and consistent use
of the code amongst all components provided. This way any
improvements/cleanups made to the shared glapi will be available to
osmesa/xlib-libgl.

>
> I understand the rationale for EGL and DRI.  But I'm asking specifically
> about xlib libgl, osmesa, and Windows ICD drivers.
>
You and Brian being one of the few few people that use/work on the
latter three, I'm really glad that to hear any feedback. Note that
this series does not force anything - just allows one to use
shared-glapi with the final remaining GL* providers - xlib-libgl.
OSMESA already has that capability.

>
> At a glance, for osmesa and xlib-libgl, forcing to split into multiple .so
> seems a step backwards.  Rather than making these easy to use and embedded,
> it adds complexity, plus potentially prevents using os mesa and libgl-xlib
> along side with the system's true libGL.so.
>
I would say that the biggest complexity is within the presence of both
static and shared glapi and the ton of spaghetti code and gets
conditionally build. After all, you know better than me the monsters
that lie in src/mapi. I'm not sure that having an extra .so makes
things that harder to use or embed, although I do see the concern.
Needless to say this is one of the reasons why I've been sitting on
these for so long. I had most of them for well over 3 months
anticipating the interesting discussion and/or bikeshed (even some on
my end :-P)

>
> Finally, it's not clear whether this would force Windows OpenGL ICD drivers
> to be split into two multiple DLLs, but I'm afraid that's a big show
> stopper.
>
As mentioned above, nothing is forced and the scons/windows topics are
more than welcome for discussions. I'm secretly hoping thst someone
will come along with a genius hack which we can use to "fold" the
shared glapi back into the original library.

>
> In summary, having the ability of using a shared glapi sounds great, but
> forcing shared glapi everywhere, sounds a bad idea.
>
I'm suspecting that people might be keen on the following idea - use
static glapi for osmesa/xlib-libgl and shared one everywhere else?

I fear that this will lead to further separation/bit-rot between the
different implementations, but it seems like the bester compromise.

Cheers,
Emil