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

[Emil Velikov]

On 22 February 2018 at 17:36, Chuck Atkins <chuck.atkins at kitware.com> wrote:
>> > 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.
>
Thanks for the explanation Chuck.

Since libGL can be shared, may I suggest giving the DRI based GLX a
try and reporting any oddities.
On the OSMesa front, well lets leave it as-is for now.

Thanks
Emil