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

[Ian Romanick]

On 06/22/2015 07:01 AM, Jose Fonseca 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.)
> 
>>
>> 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.
> 
> 
> 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.

It comes from the intersection of the assembly and the myriad threading
options.  Having TLS and shared-glapi is the only "option" for DRI
builds would be terrific.  We have a couple work loads that, especially
on Atom CPUs, are sensitive to any added overhead.  My recollection was
that GCC does not generate the code you want for the dispatch functions.

I feel like we keeping coming around to the loader/driver interface
needing some significant work.  I certainly have a bunch of ideas for
how things could be improved.  I'll start working on a proposal.

> Jose
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>