<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
> If there's a better way forward for having a minimal-dependency<br>
> software-only implementation, I'd certainly be willing to try it.  At the<br>
> moment though, gallium-xlib-glx is our path for that.<br>
><br>
</div></div>I was merely mentioning that the xlib-glx are in worse shape than the dri one.<br>
<br>
That aside:<br>
IIRC previously you mentioned that libGL/OSMesa must be static<br>
libraries. If that is still the case, then DRI based GLX won't cut it.<br>
Alternatively if you can point out any specifics that would be </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
amazing.</blockquote><div><br>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.<br></div><br>- Chuck<br></div></div></div>