yep, I'm using 10.1.0 and also noticed the same in 9.2.2.
in short static linking is essential for reasonable performance of
parallel applications on Cray systems. In this scenario the application
is duplicated across 100s/1000s of compute nodes which share a
remote-parallel file system (Lustre/GPFS). As a dynamically linked
application starts, shared library loading hit's the file system hard.
However, Cray suggests users run static linked executables. Their
application launcher bypasses the file system and copies statically
linked executable directly into a ram fs onto the set of compute nodes
that a given job is scheduled to run on. This avoids file system
contention that would be introduced by a parallel application's shared
library loading.
I maintain and support ParaView and interactive OpenGL based rendering
application on NERSC's Crays. Given that this is an interactive
application, having a reasonable startup time is important. Users have
complained and I've observed times when using shared libraries when app
startup takes more than 30 min! if we build fully static executable
startup time is reduced to seconds.
For me statically linked mesa is important, which is why I want to
report this. Without OSMesa we can't use these systems, and the new
llvmpipe OSMesa state tracker has been really awesome, allowing us to do
things we couldn't in the past without GPUs. I hope that you don't
discontinue static link support.
We have experienced some segfaults in llvmpipe OSMesa in the static
linked version (bt shows SEGV at
create_jit_texture_type.isra.1@draw_llvm.c:128). If I can reproduce this
off the Cray I will file a bug report. Thought I'd mention in case you
can confirm that there is a known issue with the static link.
Thanks
Burlen
On 03/11/2014 03:13 PM, Emil Velikov wrote:
On 11/03/14 20:31, Burlen Loring wrote:
Hi All,
Hi Burlen
When I make a static build of mesa with osmesa+llvm, all of the llvm
related symbols are undefined in the resulting libOSMesa.a archive.
There is an "la" file produced that lists the dependencies, however
shouldn't those all be linked into the installed archive? for reference
see my configure line below.
Earlier today I have pushed a patch [1] for mesa that completely
disabled static building for all of mesa.
While that may not be the reason for the problem you're seeing (afaics
you're using mesa 10.1.0 and my patch just made it into master) it
would be great if you can let us know what the your use case of
static OSMesa is, so that we can evaluate the situation.
Many thanks
Emil
P.S. With the commit [1] --enable-static --disable-shared will produce
an warning message and will fall back to --disable-static
--enable-shared.
[1]
http://cgit.freedesktop.org/mesa/mesa/commit/?id=a6efbac9fb502c4f0166e7a0680b6828e1f6926c
Burlen
Mesa-10.1.0$make distclean; autoreconf -fi; ./configure CXXFLAGS="-O2 -g
-fPIC -DDEFAULT_SOFTWARE_DEPTH_BITS=31" CFLAGS="-O2 -g -fPIC
-DDEFAULT_SOFTWARE_DEPTH_BITS=31" --enable-static=yes --enable-shared=no
--disable-xvmc --disable-glx --disable-dri --with-dri-drivers=
--with-gallium-drivers=swrast --enable-texture-float
--disable-shared-glapi --disable-egl --with-egl-platforms=
--enable-gallium-osmesa --enable-gallium-llvm=yes
--with-llvm-prefix=/work/apps/llvm/3.2/
--prefix=/work/apps/mesa-10.1.0-a && make -j2 && make -j4 install
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
