ParaView/ParaView And Mesa 3D: Difference between revisions

From KitwarePublic
Jump to navigationJump to search
 
(22 intermediate revisions by the same user not shown)
Line 3: Line 3:


= Mesa for your GPU =
= 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.
Before getting into details of Mesa graphics hardware drivers, a disclaimer. '''If you have NVIDIA or AMD 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 Linux distributions now provide thridparty closed source drivers through specialized package repositories. The details of installing vendor provided drivers in beyond the scope of this document. Please consult distribution 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.
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.
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 =
= Mesa for your CPU (i.e. without graphics hardware, and OSMesa) =
OpenGL applications require some mechanism to create and manage a rendering context.  On Linux and Unix systems using X11 and GPUs, this is typically done with the GLX library (libGL) provided by a vendor supplied graphics driver.  For systems without graphics cards or powerful GPUs, the Mesa 3D package provides the OSMesa library (Off-Screen Mesa) and several CPU based renderers providing OpenGL drivers. Here we will discuss 2 of OSMesa's renderers: ''llvmpipe'' and ''swr''.  Both Mesa's llvmpipe and swr renderers are some of the exciting recent developments in Mesa. They are threaded software based OpenGL drivers which use LLVM and clang for JIT compilation of GLSL shaders.  The llvmpipe driver for OSMesa was added in the 2013 9.2.0 release and the swr driver in the 2016 12.0.0 release.  The llvmpipe driver is available on most of Mesa's supported platforms while the swr driver is a much more highly optimized and threaded driver only available for newer x86_64 processors with AVX or AVX2 capability.  They are currently the best software based OpenGL option for ParaView and VTK in terms of both OpenGL features and performance (swr on Intel CPUs and llvmpipe on all others).  OSMesa ''classic swrast'' no longer supports the necessary OpenGL features required by newer VTK and ParaView versions.  Mesa's ''softpipe'', the single threaded reference software rederer, may still be useful in the case of a bug in the llvmpipe or swr sreivers and provides a stable fallback option.  When enabling llvmpipe, you will get softpipe for free.
OpenGL applications require some mechanism to create and manage a rendering context.  On Linux and Unix systems using X11 and GPUs, this is typically done with the GLX library (libGL) provided by a vendor supplied graphics driver.  For systems without graphics cards or powerful GPUs, the Mesa 3D package provides the OSMesa library (Off-Screen Mesa) and several CPU based renderers providing OpenGL drivers. Here we will discuss 2 of OSMesa's renderers: ''llvmpipe'' and ''swr''. They are threaded software based OpenGL drivers which use LLVM and clang for JIT compilation of GLSL shaders.  The llvmpipe driver for OSMesa was added in the 2013 9.2.0 release and the swr driver in the 2016 12.0.0 release.  The llvmpipe driver is available on most of Mesa's supported platforms while the swr driver is a much more highly optimized and threaded driver only available for newer x86_64 processors with AVX, AVX2, or AVX512 capability.  They are currently the best software based OpenGL option for ParaView and VTK in terms of both OpenGL features and performance (swr on Intel CPUs and llvmpipe on all others).  OSMesa ''classic swrast'' no longer supports the necessary OpenGL features required by newer VTK and ParaView versions.  Mesa's ''softpipe'', the single threaded reference software rederer, may still be useful in the case of a bug in the llvmpipe or swr drivers and provides a stable fallback option.  When enabling llvmpipe, you will get softpipe for free.


== Installing Mesa llvmpipe and swr drivers ==
== Installing LLVM ==
The Mesa 13.0.1 OSMesa state-tracker with either llvmpipe or swr driver is the preferred CPU based renderer for ParaView and VTK.  The following shows how to configure Mesa with a system installed LLVMOur strategy is to configure Mesa with the options necessary to provide a minimal build with only OSMesa and it's associated drivers.  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 v13.0.1 release; older or newer releases may require slightly different optionsConsult ''./configure --help'' for additional details.
LLVM is an intermediate language representation and is used by Mesa of internal representation and optimization of OpenGL shadersAs such, it is required as a dependency to build the optimized CPU drivers for Mesa, at least v6.0.0 (if not using swr then only 3.9.0 is required)Use the following to configure LLVM for use with Mesa,'s llvmpipe and swr drivers:


<source lang="bash">
<source lang="bash">
#!/bin/bash
#!/bin/bash


./configure                                        \
# Download the latest LLVM source
  --prefix=/path/to/install/mesa                    \
curl -L -O https://github.com/llvm/llvm-project/releases/download/llvmorg-12.0.1/llvm-12.0.1.src.tar.xz
  --enable-opengl --disable-gles1 --disable-gles2  \
 
  --disable-va --disable-xvmc --disable-vdpau      \
# Extract
  --enable-shared-glapi                            \
tar -xvf llvm-12.0.1.src.tar.xz
   --disable-texture-float                          \
 
   --enable-gallium-llvm --enable-llvm-shared-libs  \
# Configure
   --with-gallium-drivers=swrast,swr                \
mkdir llvm-12.0.1.bld
   --disable-dri --with-dri-drivers=                 \
cd llvm-12.0.1.bld
   --disable-egl --with-egl-platforms= --disable-gbm \
cmake                                          \
   --disable-glx                                    \
   -DCMAKE_BUILD_TYPE=Release                    \
   --disable-osmesa --enable-gallium-osmesa
   -DCMAKE_INSTALL_PREFIX=/path/to/install/llvm \
   -DLLVM_BUILD_LLVM_DYLIB=ON                    \
   -DLLVM_ENABLE_RTTI=ON                        \
   -DLLVM_INSTALL_UTILS=ON                      \
   -DLLVM_TARGETS_TO_BUILD=X86                  \
   ../llvm-12.0.1.src


# Build and install
make -j8
make -j8
make install
make install
Line 37: Line 43:
Some explanation of these options:
Some explanation of these options:


; --enable-opengl --disable-gles1 --disable-gles2
; -DCMAKE_BUILD_TYPE=Release
: Specify which APIs to enable.  Mesa will try to enable OpenGL, OpenGL ES, and OpenGL ES2 by defaultWe only need "normal OpenGL" so we're explicitly disabling the others.
: Make sure we use a release build, not debug
 
; -DLLVM_BUILD_LLVM_DYLIB=ON
: Build a dynamic libLLVM.so in addition to the a collection of static component libraries
 
; -DLLVM_ENABLE_RTTI=ON
: Certain '''r'''un-'''t'''ime '''t'''ype '''i'''nformation (RTTI) features are used by Mesa and need to be enabled
 
; -DLLVM_INSTALL_UTILS=ON
: Some of the command line utilities are need by the Mesa build that are not installed by default
 
; -DLLVM_TARGETS_TO_BUILD=X86
: The default is to build all supported backend (PowerPC, ARM, etc.).  While that's certainly do-able, it's entirely unnecessary for our purposes so restrict to only the one we need.
 
== Installing Mesa llvmpipe and swr drivers ==
The Mesa 21.3.1 OSMesa state-tracker with either llvmpipe or swr driver is the preferred CPU based renderer for headless ParaView and VTK configurations without GPU hardware.  The following shows how to configure Mesa with a system installed LLVMOur strategy is to configure Mesa with the options necessary to provide a minimal build with only OSMesa and it's associated driversThis 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 v21.3.1 release; older or newer releases may require slightly different options.
 
Before compiling, the following dependencies will need to be installed:
* meson: The build system used by Mesa since v19
* ninja: a highly parallel build tool used by meson
* python 3.x: Python 2x is no longer supported
* mako: A python module used by the mesa's build system
 
<source lang="bash">
#!/bin/bash
 
# Download and extract the latest Mesa source
curl -L -O https://archive.mesa3d.org//mesa-21.3.1.tar.xz
tar -xvf mesa-21.3.1.tar.xz
 
# Configure Mesa
mkdir mesa-21.3.10-build
cd mesa-21.3.10-build
 
meson                          \
  ../mesa-21.3.1              \
  --buildtype=release          \
  --prefix=/path/to/install    \
  -Dvulkan-drivers=            \
  -Ddri-drivers=              \
  -Dgallium-vdpau=disabled    \
  -Dgallium-xvmc=disabled      \
  -Dgallium-omx=disabled      \
  -Dgallium-va=disabled        \
  -Dgallium-xa=disabled        \
  -Dgallium-nine=false        \
  -Dgallium-opencl=disabled    \
  -Dbuild-tests=false          \
  -Degl=disabled              \
  -Dgbm=disabled              \
  -Dglx=disabled              \
  -Dplatforms=                \
  -Dglvnd=false                \
  -Dosmesa=true                \
  -Dopengl=true                \
  -Dgles1=disabled            \
  -Dgles2=disabled            \
  -Dshared-glapi=enabled      \
  -Dllvm=enabled              \
  -Dshared-llvm=enabled        \
  -Dgallium-drivers=swrast,swr
 
ninja
ninja install
</source>
 
Some explanation of these options:
 
; --buildtype=release
: The default Meson configuration is to build optimized debug builds; this ensures that a fully optimized release library is built without the additional debugging checks. '''This is particularly important when enabling the swr driver as there are known segfaults in the swr driver from internal debug checks when using ParaView and VTK'''.
 
; -Dvulkan-drivers=
: The Vulkan API is not being used so we're explicitly disabling it.
 
; -Ddri-drivers=
: Disable any drivers using Mesa's legacy driver infrastructure.


; --disable-va --disable-xvmc --disable-vdpau
; -Dgallium-vdpau=disabled -Dgallium-xvmc=disabled -Dgallium-omx=disabled -Dgallium-va=disabled -Dgallium-xa=disabled        -Dgallium-nine=false -Dgallium-opencl=disabled
: Mesa comes with several different state trackers on by default.  We don't need any of them so we explicitly disable them.
: Mesa comes with several different state trackers on by default.  We don't need any of them so we explicitly disable them.


; --disable-texture-float
; -Dbuild-tests=false
: This option specifically deals with OpenGL floating point textures. There is a questionable legal and patent issue with enabling them so only do so if you are either unaffected by this in your country / juristion or are willing to deal with the associated legal issuesSee https://cgit.freedesktop.org/mesa/mesa/tree/docs/patents.txt for more detail.
: Tests are only useful if you're actually developing Mesa.
 
; -Degl=disabled -Dgbm=disabled
: Disable the EGL library as we're not using here.
 
; -Dglx=disabled -Dplatforms=
: We're explicitly only building OSMesa so the GLX and EGL front-ends, as well as their related options, are explicitly disabledNote: If you also need to enable the GLX (possibly if trying to run the ParaView GUI over VNC) then change these to '''-Dglx=gallium-xlib -Dplatforms=x11'''.


; --enable-gallium-llvm --enable-llvm-shared-libs
; -Dglvnd=false
: LLVM is needed for much of the desired infrastructure for both the llvmpipe and swr driversIf ./configure is having trouble locating an appropriate LLVM installation, you may need to also pass the --with-llvm-prefix=/path/to/llvm/installation option.
: GLVND is the next generation OpenGL library infrastructure on Linux for GLX and EGL, both of which are disabled aboveNote: The complexities of the GLVND infrastructure are outside the scope of this guide, but if enabling GLX above you probably still want to disable this.


; --with-gallium-drivers=swrast,swr
; -Dosmesa=true
: The swrast driver enables the softpipe render and, if llvm is enabled (which it is in the previous option), then the llvmpipe driver as well.  The swr driver is the optimized Intel-specific multithreaded driver.  Leave this out if you are on an older CPU without AVX capability or on a non-Intel architecture.
: OSMesa is the only frontend we're enabling.


; --disable-dri --with-dri-drivers=
; -Dopengl=true -Dgles1=disabled -Dgles2=disabled
: Since we are using the Mesa's newer "galllium" driver infrastructure then we can explicitly disable the older DRI infrastructure
: Specify which APIs to enable.  Mesa will try to enable OpenGL, OpenGL ES, and OpenGL ES2 by default.  We only need "normal OpenGL" so we're explicitly disabling the others.


; --disable-egl --with-egl-platforms= --disable-gbm
; -Dllvm=enabled -Dshared-llvm=enabled
: We're only intrested in OSMesa so we can drop the unnecessary EGL context creation
: Enable the use of LLVM based drivers.
 
; -Dshared-glapi=enabled
: If using swr this helps reduce library sizes by breaking out common functionality used by libOSMesa and libSWR.
 
; -Dgallium-drivers=swrast,swr
: The swrast driver enables the softpipe render and, if llvm is enabled (which it is in the previous option), the llvmpipe driver.  The swr driver is the optimized Intel-specific multithreaded driver, better known as OpenSWR.  Leave '''swr''' out if you are on an older CPU without AVX capability or on a non-Intel architecture.
 
== Using the llvmpipe and swr drivers ==
=== Changing drivers at runtime ===
Using the above configuration, the resulting mesa will have a libOSMesa.so (and possibly libGL.so) containing only the softpipe, llvmpipe, and swr drivers, with llvmpipe always being the default.  To change drivers at runtime, use the GALLIUM_DRIVER environment variable, setting it to either softpipe, llvmpipe, or swr:
 
; Default behavior
<source lang="bash">
$ glxinfo | grep "^OpenGL \(renderer\|core profile version\|vendor\)"
OpenGL vendor string: Mesa/X.org
OpenGL renderer string: llvmpipe (LLVM 12.0.1, 256 bits)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 21.3.1
</source>


; --disable-glx
; softpipe
: Again, only OSMesa so no need for GLX.
<source lang="bash">
:* If you want to ''ALSO'' build libGL.so to have GLX with the softpipe, llvmpipe, and swr drivers for an X server in addition to libOSMesa.so, then change this to '''--enable-glx'''.
$ export GALLIUM_DRIVER=softpipe
$ glxinfo | grep "^OpenGL \(renderer\|core profile version\|vendor\)"
OpenGL vendor string: Mesa/X.org
OpenGL renderer string: softpipe
OpenGL core profile version string: 3.3 (Core Profile) Mesa 21.3.1
</source>


;--disable-osmesa --enable-gallium-osmesa
; llvmpipe
: Disable the older "classic" OSMesa in favor of the newer "gallium" OSMesa
<source lang="bash">
$ GALLIUM_DRIVER=llvmpipe
$ glxinfo | grep "^OpenGL \(renderer\|core profile version\|vendor\)"
OpenGL vendor string: Mesa/X.org
OpenGL renderer string: llvmpipe (LLVM 12.0.1, 256 bits)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 21.3.1
</source>
: Use the LP_NUM_THREADS environment variable to set the number of threads used for pixel shaders; vertex shaders are processed single threaded.  This is currently limited to 16 threads.  In the context of ParaView and VTK, this means that geometry operations will be single threaded but pixel operation (like volume rendering) can still be parallelized.


== Using the llvmpipe and swr drivers at runtime ==
; swr
COMMONG SOON
<source lang="bash">
$ GALLIUM_DRIVER=swr
$ glxinfo | grep "^OpenGL \(renderer\|core profile version\|vendor\)"
OpenGL vendor string: Intel Corporation
OpenGL renderer string: SWR (LLVM 12.0.1, 256 bits)
OpenGL core profile version string: 3.3 (Core Profile) Mesa 21.3.1
</source>
: Use the environment variable KNOB_MAX_WORKER_THREADS to specify the number of threads used.  swr does an effective job and parallelizing most aspect of rendering, in contract to llvmpipe which only parallelizes pixel shaders.  This currently has a limit of 256 threads.


= A comparison of OSMesa Gallium llvmpipe, OSMesa classic and, GPU Accelerated Rendering Performance =
= A comparison of OSMesa Gallium llvmpipe, OSMesa classic and, GPU Accelerated Rendering Performance =
** Note that this is currently outdated and while the relative performance numbers are still valid, OpenSWR is not present in these tests.
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 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.


Line 83: Line 210:
cmake \
cmake \
   ...
   ...
   -DPARAVIEW_BUILD_QT_GUI=OFF \
   -DPARAVIEW_BUILD_QT_GUI=OFF                                 \
   -DVTK_USE_X=OFF \
   -DVTK_USE_X=OFF                                             \
   -DOPENGL_INCLUDE_DIR={MESA_INSTALL_PREFIX}/include \
   -DOPENGL_INCLUDE_DIR=IGNORE                                  \
   -DOPENGL_gl_LIBRARY={MESA_INSTALL_PREFIX}/lib/libOSMesa.[so|a] \
  -DOPENGL_xmesa_INCLUDE_DIR=IGNORE                            \
   -DOPENGL_glu_LIBRARY={MESA_INSTALL_PREFIX}/lib/libGLU.[so|a] \
   -DOPENGL_gl_LIBRARY=IGNORE                                  \
   -DVTK_OPENGL_HAS_OSMESA=ON \
  -DOSMESA_INCLUDE_DIR=${MESA_INSTALL_PREFIX}/include          \
   -DOSMESA_INCLUDE_DIR={MESA_INSTALL_PREFIX}/include \
   -DOSMESA_LIBRARY=${MESA_INSTALL_PREFIX}/lib/libOSMesa.[so|a] \
   -DOSMESA_LIBRARY={MESA_INSTALL_PREFIX}/lib/libOSMesa.[so|a] \
   -DVTK_OPENGL_HAS_OSMESA=ON                                   \
  $*
   -DVTK_USE_OFFSCREEN=OFF                                      \
   ...


make -j32
make -j32
Line 98: Line 226:


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.
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 [[http://lists.freedesktop.org/archives/mesa-dev/2012-January/017894.html (Mesa-dev post)]]). As such, if it does not exist on your system, it can be separately downloaded and installed from the [[ftp://ftp.freedesktop.org/pub/mesa/glu/ libGLU freedesktop.org ftp]].


== MPI-Parallel rendering with OSMesa Gallium llvmpipe state-tracker ==
== MPI-Parallel rendering with OSMesa Gallium llvmpipe state-tracker ==

Latest revision as of 17:33, 10 December 2021

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 NVIDIA or AMD 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 Linux distributions now provide thridparty closed source drivers through specialized package repositories. The details of installing vendor provided drivers in beyond the scope of this document. Please consult distribution 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.

Mesa for your CPU (i.e. without graphics hardware, and OSMesa)

OpenGL applications require some mechanism to create and manage a rendering context. On Linux and Unix systems using X11 and GPUs, this is typically done with the GLX library (libGL) provided by a vendor supplied graphics driver. For systems without graphics cards or powerful GPUs, the Mesa 3D package provides the OSMesa library (Off-Screen Mesa) and several CPU based renderers providing OpenGL drivers. Here we will discuss 2 of OSMesa's renderers: llvmpipe and swr. They are threaded software based OpenGL drivers which use LLVM and clang for JIT compilation of GLSL shaders. The llvmpipe driver for OSMesa was added in the 2013 9.2.0 release and the swr driver in the 2016 12.0.0 release. The llvmpipe driver is available on most of Mesa's supported platforms while the swr driver is a much more highly optimized and threaded driver only available for newer x86_64 processors with AVX, AVX2, or AVX512 capability. They are currently the best software based OpenGL option for ParaView and VTK in terms of both OpenGL features and performance (swr on Intel CPUs and llvmpipe on all others). OSMesa classic swrast no longer supports the necessary OpenGL features required by newer VTK and ParaView versions. Mesa's softpipe, the single threaded reference software rederer, may still be useful in the case of a bug in the llvmpipe or swr drivers and provides a stable fallback option. When enabling llvmpipe, you will get softpipe for free.

Installing LLVM

LLVM is an intermediate language representation and is used by Mesa of internal representation and optimization of OpenGL shaders. As such, it is required as a dependency to build the optimized CPU drivers for Mesa, at least v6.0.0 (if not using swr then only 3.9.0 is required). Use the following to configure LLVM for use with Mesa,'s llvmpipe and swr drivers:

<source lang="bash">

  1. !/bin/bash
  1. Download the latest LLVM source

curl -L -O https://github.com/llvm/llvm-project/releases/download/llvmorg-12.0.1/llvm-12.0.1.src.tar.xz

  1. Extract

tar -xvf llvm-12.0.1.src.tar.xz

  1. Configure

mkdir llvm-12.0.1.bld cd llvm-12.0.1.bld cmake \

 -DCMAKE_BUILD_TYPE=Release                    \
 -DCMAKE_INSTALL_PREFIX=/path/to/install/llvm  \
 -DLLVM_BUILD_LLVM_DYLIB=ON                    \
 -DLLVM_ENABLE_RTTI=ON                         \
 -DLLVM_INSTALL_UTILS=ON                       \
 -DLLVM_TARGETS_TO_BUILD=X86                   \
 ../llvm-12.0.1.src
  1. Build and install

make -j8 make install </source>

Some explanation of these options:

-DCMAKE_BUILD_TYPE=Release
Make sure we use a release build, not debug
-DLLVM_BUILD_LLVM_DYLIB=ON
Build a dynamic libLLVM.so in addition to the a collection of static component libraries
-DLLVM_ENABLE_RTTI=ON
Certain run-time type information (RTTI) features are used by Mesa and need to be enabled
-DLLVM_INSTALL_UTILS=ON
Some of the command line utilities are need by the Mesa build that are not installed by default
-DLLVM_TARGETS_TO_BUILD=X86
The default is to build all supported backend (PowerPC, ARM, etc.). While that's certainly do-able, it's entirely unnecessary for our purposes so restrict to only the one we need.

Installing Mesa llvmpipe and swr drivers

The Mesa 21.3.1 OSMesa state-tracker with either llvmpipe or swr driver is the preferred CPU based renderer for headless ParaView and VTK configurations without GPU hardware. The following shows how to configure Mesa with a system installed LLVM. Our strategy is to configure Mesa with the options necessary to provide a minimal build with only OSMesa and it's associated drivers. 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 v21.3.1 release; older or newer releases may require slightly different options.

Before compiling, the following dependencies will need to be installed:

  • meson: The build system used by Mesa since v19
  • ninja: a highly parallel build tool used by meson
  • python 3.x: Python 2x is no longer supported
  • mako: A python module used by the mesa's build system

<source lang="bash">

  1. !/bin/bash
  1. Download and extract the latest Mesa source

curl -L -O https://archive.mesa3d.org//mesa-21.3.1.tar.xz tar -xvf mesa-21.3.1.tar.xz

  1. Configure Mesa

mkdir mesa-21.3.10-build cd mesa-21.3.10-build

meson \

 ../mesa-21.3.1               \
 --buildtype=release          \
 --prefix=/path/to/install    \
 -Dvulkan-drivers=            \
 -Ddri-drivers=               \
 -Dgallium-vdpau=disabled     \
 -Dgallium-xvmc=disabled      \
 -Dgallium-omx=disabled       \
 -Dgallium-va=disabled        \
 -Dgallium-xa=disabled        \
 -Dgallium-nine=false         \
 -Dgallium-opencl=disabled    \
 -Dbuild-tests=false          \
 -Degl=disabled               \
 -Dgbm=disabled               \
 -Dglx=disabled               \
 -Dplatforms=                 \
 -Dglvnd=false                \
 -Dosmesa=true                \
 -Dopengl=true                \
 -Dgles1=disabled             \
 -Dgles2=disabled             \
 -Dshared-glapi=enabled       \
 -Dllvm=enabled               \
 -Dshared-llvm=enabled        \
 -Dgallium-drivers=swrast,swr

ninja ninja install </source>

Some explanation of these options:

--buildtype=release
The default Meson configuration is to build optimized debug builds; this ensures that a fully optimized release library is built without the additional debugging checks. This is particularly important when enabling the swr driver as there are known segfaults in the swr driver from internal debug checks when using ParaView and VTK.
-Dvulkan-drivers=
The Vulkan API is not being used so we're explicitly disabling it.
-Ddri-drivers=
Disable any drivers using Mesa's legacy driver infrastructure.
-Dgallium-vdpau=disabled -Dgallium-xvmc=disabled -Dgallium-omx=disabled -Dgallium-va=disabled -Dgallium-xa=disabled -Dgallium-nine=false -Dgallium-opencl=disabled
Mesa comes with several different state trackers on by default. We don't need any of them so we explicitly disable them.
-Dbuild-tests=false
Tests are only useful if you're actually developing Mesa.
-Degl=disabled -Dgbm=disabled
Disable the EGL library as we're not using here.
-Dglx=disabled -Dplatforms=
We're explicitly only building OSMesa so the GLX and EGL front-ends, as well as their related options, are explicitly disabled. Note: If you also need to enable the GLX (possibly if trying to run the ParaView GUI over VNC) then change these to -Dglx=gallium-xlib -Dplatforms=x11.
-Dglvnd=false
GLVND is the next generation OpenGL library infrastructure on Linux for GLX and EGL, both of which are disabled above. Note: The complexities of the GLVND infrastructure are outside the scope of this guide, but if enabling GLX above you probably still want to disable this.
-Dosmesa=true
OSMesa is the only frontend we're enabling.
-Dopengl=true -Dgles1=disabled -Dgles2=disabled
Specify which APIs to enable. Mesa will try to enable OpenGL, OpenGL ES, and OpenGL ES2 by default. We only need "normal OpenGL" so we're explicitly disabling the others.
-Dllvm=enabled -Dshared-llvm=enabled
Enable the use of LLVM based drivers.
-Dshared-glapi=enabled
If using swr this helps reduce library sizes by breaking out common functionality used by libOSMesa and libSWR.
-Dgallium-drivers=swrast,swr
The swrast driver enables the softpipe render and, if llvm is enabled (which it is in the previous option), the llvmpipe driver. The swr driver is the optimized Intel-specific multithreaded driver, better known as OpenSWR. Leave swr out if you are on an older CPU without AVX capability or on a non-Intel architecture.

Using the llvmpipe and swr drivers

Changing drivers at runtime

Using the above configuration, the resulting mesa will have a libOSMesa.so (and possibly libGL.so) containing only the softpipe, llvmpipe, and swr drivers, with llvmpipe always being the default. To change drivers at runtime, use the GALLIUM_DRIVER environment variable, setting it to either softpipe, llvmpipe, or swr:

Default behavior

<source lang="bash"> $ glxinfo | grep "^OpenGL \(renderer\|core profile version\|vendor\)" OpenGL vendor string: Mesa/X.org OpenGL renderer string: llvmpipe (LLVM 12.0.1, 256 bits) OpenGL core profile version string: 4.5 (Core Profile) Mesa 21.3.1 </source>

softpipe

<source lang="bash"> $ export GALLIUM_DRIVER=softpipe $ glxinfo | grep "^OpenGL \(renderer\|core profile version\|vendor\)" OpenGL vendor string: Mesa/X.org OpenGL renderer string: softpipe OpenGL core profile version string: 3.3 (Core Profile) Mesa 21.3.1 </source>

llvmpipe

<source lang="bash"> $ GALLIUM_DRIVER=llvmpipe $ glxinfo | grep "^OpenGL \(renderer\|core profile version\|vendor\)" OpenGL vendor string: Mesa/X.org OpenGL renderer string: llvmpipe (LLVM 12.0.1, 256 bits) OpenGL core profile version string: 4.5 (Core Profile) Mesa 21.3.1 </source>

Use the LP_NUM_THREADS environment variable to set the number of threads used for pixel shaders; vertex shaders are processed single threaded. This is currently limited to 16 threads. In the context of ParaView and VTK, this means that geometry operations will be single threaded but pixel operation (like volume rendering) can still be parallelized.
swr

<source lang="bash"> $ GALLIUM_DRIVER=swr $ glxinfo | grep "^OpenGL \(renderer\|core profile version\|vendor\)" OpenGL vendor string: Intel Corporation OpenGL renderer string: SWR (LLVM 12.0.1, 256 bits) OpenGL core profile version string: 3.3 (Core Profile) Mesa 21.3.1 </source>

Use the environment variable KNOB_MAX_WORKER_THREADS to specify the number of threads used. swr does an effective job and parallelizing most aspect of rendering, in contract to llvmpipe which only parallelizes pixel shaders. This currently has a limit of 256 threads.

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

    • Note that this is currently outdated and while the relative performance numbers are still valid, OpenSWR is not present in these tests.

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=IGNORE                                  \
 -DOPENGL_xmesa_INCLUDE_DIR=IGNORE                            \
 -DOPENGL_gl_LIBRARY=IGNORE                                   \
 -DOSMESA_INCLUDE_DIR=${MESA_INSTALL_PREFIX}/include          \
 -DOSMESA_LIBRARY=${MESA_INSTALL_PREFIX}/lib/libOSMesa.[so|a] \
 -DVTK_OPENGL_HAS_OSMESA=ON                                   \
 -DVTK_USE_OFFSCREEN=OFF                                      \
 ...

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.

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