[Paraview] Building ParaView v5.1.2 on Linux from source with support for GPU and SWR.

Albina, Frank frank.albina at sauber-motorsport.com
Fri Oct 7 05:37:25 EDT 2016


Chuck,

thanks to your help, I could compile ParaView v5.1.2 with Mesa v12.0.3 (release version, not from GIT repository) using the master git checkout (hash 26eb1fa8f5364242d9f9c03b598f0ee735cf88e4) from last week.

It was not easy but probably due my lack of experience using the superbuild system and not knowing which external projects I had to enable/disable.

A few comments regarding the build on my system (OpenSuSE 12.3):

1.     Cmake v3.6.x is required for building. Not a big deal but this is new wrt. the release checkout.

2.     There are still libraries built into /path/to/build/install/lib64.

·         projects/apple-unix/szip.cmake

·         projects/unix/mesa.common.cmake

·         projects/apple-unix/freetye.cmake
For these libraries, I had to specify in the cmake file the additional option –libdir=<INSTALL_DIR>/lib

3.     Building Mesa v12.0.3 works like a charm. However, the libOSMesa relies on additional libraries such as:

·         libglapi.so

·         libswrAVX.so

·         libswrAVX2.so
which are not copied into the archive when packing the binaries using: “ctest -V -R cpack-paraviewsdk-TGZ”

4.     Compared to the ParaView v5.1.2 binary for Linux, the compiled version with mesa v12.0.3 is substantially slower than with the OpenSWR version shipped with the binary.

I have let my standard benchmark running to give you some numbers. The benchmark consists in rendering pressure-contours on a generic F1  & sports car as shown hereafter. The surface mesh of the sports car is roughly twice as fine as on the F1 car.

[cid:image001.jpg at 01D2208D.A36EF080]
Rendering time

Generic F1 car

Generic sports car

PV 5.1.2 binary

27.06s

77.95s

PV 5.1.2 MESA3D v12.0.3

81.10s

272.05s




From the comparison, the version compiled with MESA 3D v12.0.3 is slower by a factor of 3 to 3.5. The compiler used is gcc v4.8.5 and in all cases the same server has been used. The SWR AVX2 rendering was set by giving –mesa-swr-avx2 from the command line for the downloaded binary, by setting the environment variable GALLIUM_DRIVER=swr for the compiled version.



Is this something which was expected? Or did I miss something when compiling the source code?


Thank you very much in advance for any feedback.

Cheers,

Frank.

From: ParaView [mailto:paraview-bounces at paraview.org] On Behalf Of Albina, Frank
Sent: Donnerstag, 29. September 2016 13:55
To: Chuck Atkins; Ben Boeckel
Cc: Del Citto, Francesco; paraview at paraview.org
Subject: Re: [Paraview] Building ParaView v5.1.2 on Linux from source with support for GPU and SWR.

Hi Chuck,
Thank you very much for your reply. It is very interesting and I will try my best to get ParaView compiled following your recommendations.
Unfortunately, others duties are holding me off this week from concentrating on this but I will share my test results comparing ParaView on GPU, with mesa-llvm and mesa-swr-avx2.
Talk to you soon.
Best regards,
Frank.
From: Chuck Atkins [mailto:chuck.atkins at kitware.com]
Sent: Mittwoch, 28. September 2016 21:18
To: Ben Boeckel
Cc: Albina, Frank; David E DeMarle; Del Citto, Francesco; paraview at paraview.org<mailto:paraview at paraview.org>
Subject: Re: [Paraview] Building ParaView v5.1.2 on Linux from source with support for GPU and SWR.

> My intention is to compile paraview without GUI to run it in batch on
> our cluster. This is the main reason why I am using a specific test
> suite to check the performance of mesa-llvm vs. mesa-swr vs. GPU. At
> the moment, on CPUs supporting AVX2 instruction set, mesa-swr shows a
> very decent performance. Hence, my interest also to try out the latest
> mesa 12.0.3 version, which I have downloaded today and started
> compiling. In this regard, do you have any configuration options you
> can share for use in offscreen mode? If this is handled already by the
> latest superbuild version, then please disregard the questions above.

Chuck (Cc'd) does this quite a bit. There are scripts he has committed
which are used to build for specific platforms which you may be able to
start using, but he's the best source of instructions for those.

Hi Frank,

The updated superbuild uses a common shared set of packages that we use for several different projects and then the top level project which is ParaView specific. To use this, you'll want to check out the current master branch in the paraview-superbuild, run "git submodule init", and then "git submodule update".  This will put you at the current state of things.

You can browse the build script I have committed in Scripts/sites for linux clusters and Cray systems at Los Alamos National Labs and the DoD HPC network.  They but they're a bit complicated though as I use them in a very generic fashion with lots of options for a lot of different build configurations.  The gist of it though is to encode all of the options you would need to turn on in a pre-configured CMake cache script. Note that this is actually a CMake script that sets the initial cache values and not and not just a list of variables like in CMakeCache.txt .  See cmake/sites for a few examples.  Doing this simplifies your build to just:
cd /path/to/build/location
cmake -C /path/to/MySystem-Cache.cmake /path/to/superbuild/source

# no -j here but don't worry, the subprojects will build in parallel
make

# Make the resulting ParaView package
ctest -R cpack-paraview-TGZ

The end result is ParaView-5.1.2-OpenGL2-MPI-Linux-64bit.tar.gz that you can extract anywhere to install.  Using ctest to drive the packaging is a bit weird, I know, but trust me that there were various reasons for that which could warrant it's own separate thread.

This allows you to keep MySystem-Cache.cmake under source control to maintain a consistent build.  For your configuration, the specific options of interest to run on are ENABLE_osmesa and ENABLE_ospray.  Our default configuration of osmesa will enable SWR.  What you'll end up with is a pvserver / pvbatch that uses OSMesa for off-screen CPU based rendering without X but with both llvmpipe and swr drivers built.  You can switch between the by setting the GALLIUM_DRIVER env var to either llvmpipe or swr.
Hope that gives you a good place to get started.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview/attachments/20161007/281dfa6a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 39206 bytes
Desc: image001.jpg
URL: <http://public.kitware.com/pipermail/paraview/attachments/20161007/281dfa6a/attachment.jpg>


More information about the ParaView mailing list