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