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

[Jose Fonseca]

On 22/06/15 19:51, Emil Velikov wrote:
> On 22 June 2015 at 15:01, Jose Fonseca <jfonseca at vmware.com> wrote:
>> On 19/06/15 23:09, Emil Velikov wrote:
>>>
>>> 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'm perfectly happy with removing the configure option.
>>
>> And I understand the benefits of unified code paths, but I believe that for
>> this particular case, the difference in requirements really demands the
>> separate code paths.
>>
>>>> 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?
>>
>>
>> Yes, that sounds reasonable for me.  (Needs libgl-gdi too.)
>>
> Indeed. Everything gdi is build only via scons so we'll touch it only if needed.
>
>>>
>>> I fear that this will lead to further separation/bit-rot between the
>>> different implementations, but it seems like the bester compromise.
>>
>>
>> I don't feel strongly between: a) using the same source code for both
>> static/shared glapi (switched by a pre-processor define), or b) only share
>> the interface but have shared/static glapi implementations.  I'm actually
>> not that familiar with that code.
>>
>>
>> Either way, we can have two glapi build targets (a shared-glapi and a
>> static-glapipe) side-by-side, so that there are no more source-wide
>> configure flags.
>>
> In theory it should be fine, in practise... I'm rather cautious as
> mapi is the most convoluted part in mesa, and with the
> "subdir-objects" option being toggled soon things may go (albeit
> unlikely) subtly haywire.
>
>>
>> I believe a lot of the complexity of that code comes from assembly.  I
>> wonder if it's really justified nowadays (and even if it is, whether it
>> would be better served with GNU C assembly.) Futhermore, I believe on
>> Windows we use any assembly, so if we split shared/static glapi source code,
>> we could probably abandon assembly from the static-glapi.
>>
> I'm not 100% sure but I'd suspect that Cygwin might use it when
> combined with swrast_dri. Don't know what others use - iirc some of
> the BSD folks are moving over to llvm. That I aside there is a massive
> amount of #ifdef spaghetti, apart from the assembly code.
>
> Can I have your ack/nack on the idea of having shared-glapi available
> for xlib-libgl (patches 2, 3 and 4), until we have both glapi's built
> in in parallel ? As mentioned originally, currently we fail to build
> if one enabled gles* and xlib-libgl and adding another hack in
> configure.ac is feel like flocking up a dead horse.

I rarely use auto conf myself, but the mentioned 2-4 patches look OK to me.

Acked-by: Jose Fonseca <jfonseca at vmware.com>