ParaView/ParaView And Mesa 3D

From KitwarePublic
< ParaView
Revision as of 00:04, 17 September 2016 by Lokman (talk | contribs) (Add link to wiki providing a recipe for building ParaView with OSMesa)
Jump to navigationJump to search

Read this first

ParaView and VTK make use of OpenGL for rendering. Most operating systems provide a default OpenGL library. If you're running a Windows or Mac OSX operating system, this page is not for you. On Windows download and install the latest drivers for your system's graphics hardware. On Apple Mac OSX just use the default OS provided drivers. On Linux the default OpenGL drivers are typically provided by Mesa. Mesa is an open source OpenGL implementation that supports a wide range of graphics hardware each with it's own back-end called a renderer. Mesa also provides several software based renderers for use on systems without graphics hardware. If you're running a Linux OS on a system without graphics hardware then this page is for you.

Mesa for your GPU

Before getting into details of Mesa graphics hardware drivers, a disclaimer. If you have graphics hardware Mesa is not your best option. To get the best performance from your graphics card you'll need to install the vendor provided driver. Vendor provided OpenGL drivers are typically much faster of a much higher quality than Mesa's which can be quite buggy. Many distros now provide thridparty non-opensource source drivers through specialized package repositories. The details of installing vendor provided drivers in beyond the scope of this document. Please consult distro and/or vendor specific documentation.

If you're running a Linux OS with X11 and graphics hardware and have not installed any OpenGL libraries you're probably already using Mesa! Note that the windowing system, in this case X11, is required for on-screen interactive rendering. On Linux systems the easiest way to install Mesa is through your distro's package manager. Most distros also provide packages for Mesa's software based renderers as well. Unfortunately, some OpenGL features may be disabled by your distro's package maintainers to avoid patent or other licensing restrictions. If you find that this is the case then you'll likely want to build Mesa from source. Given the depth and breadth of the universe of hardware that Mesa supports, building Mesa for use on systems with graphics hardware is beyond the scope of this article. Please consult the Mesa documentation directly.

Configuring VTK and ParaView with X11 or hardware accelerated Mesa only requires pointing VTK to the desired Mesa install and ensuring that LD_LIBRARY_PATH includes your Mesa install.

OSMesa, Mesa without graphics hardware

On Unix/Linux systems lacking graphics hardware one of Mesa's OSMesa(a collection of off screen renderers) renderer can provide OpenGL. Here we will discus two of OSMesa's renderers: Gallium llvmpipe and classic. Mesa's Gallium llvmpipe renderer is one of the exciting recent developments in Mesa. It is a threaded software based OpenGL which uses LLVM and clang for JIT compilation of GLSL shaders. Gallium llvmpipe support for OSMesa was added in the 2013 9.2.0 release. It's currently the best software based OpenGL option for ParaView and VTK in terms of both OpenGL features and performance. OSMesa classic, the legacy implementation, may still be useful in the case of a bug in the llvmpipe renderer and provides a stable fallback option.

Installing OSMesa Gallium llvmpipe state-tracker

The Mesa 9.2.2 OSMesa Gallium llvmpipe state-tracker is the preferred Mesa back-end renderer for ParaView and VTK. The following shows how to configure it with system installed LLVM. Our strategy is to configure Mesa with the minimal options needed for OSMesa. This greatly simplifies the build as many of the other drivers/renderers depend on X11 or other libraries. The following set of options are from Mesa v9.2.2 release, older or newer releases may require slightly different options, consult ./configure --help for the details.

<source lang="bash">

  1. !/bin/bash

make -j4 distclean # if in an existing build

autoreconf -fi

./configure \

   CXXFLAGS="-O2 -g -DDEFAULT_SOFTWARE_DEPTH_BITS=31" \
   CFLAGS="-O2 -g -DDEFAULT_SOFTWARE_DEPTH_BITS=31" \
   --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-shared-libs \
   --prefix=/work/apps/mesa/9.2.2/llvmpipe

make -j2 make -j4 install </source>

Some explanation of these options:

DEFAULT_SOFTWARE_DEPTH_BITS=31
This sets the internal depth buffer precision for the OSMesa rendering context. In our experrience this is necessary to avoid z-buffer fighting during parallel rendering. Note that we've used this in-place of --with-osmesa-bits=32, which sets both depthbuffer and colorbuffers to 32 bit precision. Because of a bug in Mesa this introduces over 80 ctest regression failures in VTK related to line drawing.
--enable-texture-float
Floating point textures are disabled by default due to patent restrictions. This must be enabled for many advanced VTK algorithms.

Installing Classic OSMesa

Classic OSMesa is the legacy back-end renderer. It may be useful if there's a bug in the Gallium llvmpipe renderer prevent a rendering feature that you really need. However note that it's much slower and does not support all of the OpenGL features that llvmpipe Gallium does.

<source lang="bash">

  1. !/bin/bash

make -j4 distclean # if in an existing build

autoreconf -fi

./configure \

   CXXFLAGS="-O2 -g -DDEFAULT_SOFTWARE_DEPTH_BITS=31" \
   CFLAGS="-O2 -g -DDEFAULT_SOFTWARE_DEPTH_BITS=31" \
   --disable-xvmc \
   --disable-glx \
   --disable-dri \
   --with-dri-drivers="" \
   --with-gallium-drivers="" \
   --enable-texture-float \
   --disable-shared-glapi \
   --disable-egl \
   --with-egl-platforms="" \
   --enable-osmesa \
   --enable-gallium-llvm=no \
   --prefix=/work/apps/mesa/9.2.2/classic

make -j2 make -j4 install </source>

Note that these are the configure options from Mesa v9.2.2, the current release as of this writing. These may be slightly different in older or newer releases, consult ./configure --help for the specific details.

A comparison of OSMesa Gallium llvmpipe, OSMesa classic and, GPU Accelerated Rendering Performance

The following chart shows the run time of VTK's Rendering ctests with OSMesa classic, Gallium llvmpipe OSMesa state-tracker, and an ATI Radeon HD 7870. The CPU on the test sytsem is a 4 core(8 thread) Intel(R) Core(TM) i7-4771 CPU @ 3.50GHz. The ATI driver used is AMD Catalyst 13.11-beta6. Run times were obtained by running each ctest twice consecutively discarding the first time. Tests that took less than 1 second were discarded, as were tests that failed on any one of the renderers. Note results are reported in cases where Classic OSMesa doesn't provide all the extensions, but Gallium llvmpipe does. For example classic OSMesa doesn't provide render buffer float. In these cases the run time reported for the classic OSMesa is ~0.

The results show that Gallium llvmpipe OSMesa state tracker is quite a bit better across the board and supports more rendering algorithms than OSMesa classic. This especially so for GPU accelerated volume rendering.

Osmesa-rendering-sm.png

Configuring ParaView for use with OSMesa

Configure ParaView as described on ParaView:Build And Install. The only cmake variables that need to be updated are:

<source lang="bash">

  1. !/bin/bash

cmake \

 ...
 -DPARAVIEW_BUILD_QT_GUI=OFF \
 -DVTK_USE_X=OFF \
 -DOPENGL_INCLUDE_DIR={MESA_INSTALL_PREFIX}/include \
 -DOPENGL_gl_LIBRARY={MESA_INSTALL_PREFIX}/lib/libOSMesa.[so|a] \
 -DOPENGL_glu_LIBRARY={MESA_INSTALL_PREFIX}/lib/libGLU.[so|a] \
 -DVTK_OPENGL_HAS_OSMESA=ON \
 -DOSMESA_INCLUDE_DIR={MESA_INSTALL_PREFIX}/include \
 -DOSMESA_LIBRARY={MESA_INSTALL_PREFIX}/lib/libOSMesa.[so|a] \
 $*

make -j32 make -j32 install </source>

The rest on the configure and build process for ParaView remains as described on ParaView:Build And Install. Note that all of these build options with the exception of PARAVIEW_BUILD_QT_GUI are VTK options, thus this also describes how to configure VTK without ParaView.

libGLU is no longer packaged as part of Mesa (since early 2012, approximately Mesa-8 [(Mesa-dev post)]). As such, if it does not exist on your system, it can be separately downloaded and installed from the [libGLU freedesktop.org ftp].

An example io building ParaView (and Catalyst) with OSMesa can be found in ParaView:_Build_And_Install_on_Grid5000_testbed

MPI-Parallel rendering with OSMesa Gallium llvmpipe state-tracker

When running ParaView in parallel with MPI one should consider how best to set the number of rendering threads used by the llvmpipe renderer. The number of rendering threads may be set using the LP_NUM_THREADS environment variable. Our parallel benchmarks of the surface LIC painter on one NERSC Edison compute node showed that the best performance was achieved when the total number of rendering threads per node was equal to the number of available hyper threads. As of Mesa 9.2.2 only the fragment pipeline is threaded. This has some important implications for parallel rendering of large datasets. First, it's important to use a mix of MPI parallelism as well as rendering threads because MPI parallelism is the only option for speeding up vertex operations. Keep in mind that generally speaking with large datasets the vertex pipeline will have more work to do than the fragment pipeline. Also, note that only algorithms that have heavy fragment shader use, such as GPU accelerated volume rendering, surface LIC, depth peeling, etc, will see a substantial benefits when using large numbers of threads. Fixed-function algorithms will not generally see the same benefit. Finally note that Mesa has a hard coded compile time limit on the number of threads set by the LP_MAX_THREADS macro, which in v9.2.2 is 16 threads.

Fig 1a: Surface LIC benchmark 1 MPI process with between 1 and 16 rendering threads. The plot shows that vertex operations, shown in teal, aren't threaded, but account for roughly 1/2 of the serial rendering time. The other colors represent fragment operations that benefit from additional rendering threads.
Fig 1b: Surface LIC benchmark with between 1 and 16 MPI processes and 16 rendering threads. The plot shows that MPI parallelism can be used to speedup vertex operations. Note that using more rendering threads than the number of hyperthreads available on the node slows down the fragment operations.

Can ParaView be built with X11/GPU accelerated OpenGL and OSMesa in the same build?

No, this is not currently possible due to library symbol conflicts. You need to choose one or the other for each build. Note that it is possible to use OSMesa rendering in the server and hardware accelerated OpenGL in the client, by having two builds. In this scenario, the client configured for X11/GPU accelerated OpenGL, and the second for server configured to use OSMesa OpenGL. You'll need to run in client-server mode.

Link to the old page

I'd like to remove this link. ParaView/ParaView_And_Mesa_3D_tmp