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 <jfons...@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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
