[Mesa-stable] [PATCH v2] glx: Properly handle cases where screen creation fails

[Chuck Atkins]

>
> > If there's a better way forward for having a minimal-dependency
> > software-only implementation, I'd certainly be willing to try it.  At the
> > moment though, gallium-xlib-glx is our path for that.
> >
> I was merely mentioning that the xlib-glx are in worse shape than the dri
> one.
>
> That aside:
> IIRC previously you mentioned that libGL/OSMesa must be static
> libraries. If that is still the case, then DRI based GLX won't cut it.
> Alternatively if you can point out any specifics that would be

amazing.


libGL is fine shared since we typically only use it on the client side with
a single process.  We do still need to build both shared and static
libOSMesa though, typically on Cray systems.  The use case is for running
~50k processes across several thousand machines, all loading the
application from the same shared file system.  Using shared libraries in
that situation poses a significant scaling problem with all 50k processes
trying to load hundreds of small files from the same shared filesystem at
the same time, and can cause application startup times to climb to 20m on a
good scenario, over an hour at worst.  In this case, static libraries
bypass the problem entirely since there's only a single fat executable to
load instead of countless small SOs.  Note that we have the same problem
with Python so we end up building a frozen python in this case to address
it.  This is also the motivation for the patch a month ago that let's
libswrARCH.so bypass dlopen and just be builtin when only using a single
architecture.

- Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-stable/attachments/20180222/cde80af4/attachment.html>