On 22 February 2018 at 17:36, Chuck Atkins <chuck.atk...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
