On 12/03/14 00:08, Burlen Loring wrote:
yep, I'm using 10.1.0 and also noticed the same in 9.2.2.
In that case "it wasn't me" ;-)
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.
Had some additional patches that cleans up mesa's build a bit further
but I guess I'll bring back (classic and gallium) static osmesa first.
Especially considering the numbers you've quoted.
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.
AFAIK static linking with llvm is a bit of a hit and miss. For that
reason mesa 10.2 may be building against shared llvm. Then again I do
not work on that part of mesa, so take this with a pinch of salt.
Brian Paul is the only person that I've seen working/bug fixing osmesa
so I'm guessing that he'll take a look in due time. Meanwhile it may be
worth filing bug report(s) for these two boogers :-)
Cheers,
Emil
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
