ParaView 5.0 / VTK 7.0 changes the default rendering engine that is a totally new, rewritten implementation that uses newer OpenGL features for improved rendering performance on modern devices. That does mean, however, that older OpenGL implementations including old graphics cards/drivers builds will no longer work.
On several Linux systems, including major super-computers, Mesa3D has been the way to get OpenGL support on nodes without GPUs. With the new rendering engine totally abandoning fixed OpenGL pipeline and heavily relying on OpenGL 3.2 core features, it’s easy to get a Mesa build that will either perform poorly or worst case, just not work. With this blog, I describe ways get “good” Mesa builds for various configurations. Note, this is not an exhaustive list. I am sure there are other ways of getting this going. These are just ways that I’ve tried and tested with that may be useful to the ParaView community. Feel free to email me (or use the comments sections) to provide additions or edits.
First things first, we’ll limit this discussion to Mesa 11.1. Also, we will ignore hardware accelerated builds of Mesa and stick with software rendering. Given that ParaView/VTK now heavily uses GLSL shaders, for optimal performance, it’s highly recommended that you use Gallium with LLVM support when building Mesa. This renderer is called llvmpipe
Off-screen Mesa (OSMesa)
OSMesa is used for ParaView builds on systems that do not have an X server available/accessible. ParaView builds with OSMesa will only include command line executables, like pvserver, pvbatch, pvpython, etc. that do not have a GUI.
Here’s how I built my OSMesa:
./configure \ --disable-xvmc \ --disable-glx \ --disable-dri \ --with-dri-drivers= \ --with-gallium-drivers=swrast \ --enable-texture-float \ --disable-egl \ --with-egl-platforms= \ --enable-gallium-osmesa \ --enable-gallium-llvm=yes \ --prefix=<install prefix>
With Mesa 11.1 or earlier, unfortunately there is no way to get a OpenGL 3.2 rendering context. A workaround to set an environment variable that fakes the version for the context created i.e. set MESA_GL_VERSION_OVERRIDE to 3.2. This, however is more of a hack and things will fail miserable if any of the rendering code attempted to use a 3.2 feature not supported by the true context provided.
Thanks to Brian Paul, a fix for this is planned for Mesa 11.2 (and potentially, Mesa 11.1.1). Alternatively, use the attached patch for Mesa (mesa.patch). This adds a new osmesa API that allows VTK to create a OpenGL 3.2 context when using OSMesa.
Onscreen Mesa (Mesa + llvmpipe)
For onscreen use-cases, you’d need a build of Mesa with X support. I haven’t been able to get a Mesa+X build that uses llvmpipe renderer using configure. I had to use scons. Here’s how I built that.
scons build=release texture_float=yes libgl-xlib
That builds a collection of libGL.so* libraries under linux-x86_64/gallium/targets/libgl-xlib/. These are the GL libraries you need.
Onscreen Mesa (Mesa + openswr)
Another alternative to using llvmpipe is using Intel’s OpenSWR. While it’s still in Alpha stage, it’s fairly easy to build and try out. Just checkout the latest (which at the time of this post was the branch 11.0-openswr) from the OpenSWR-Mesa Github, and build as follows:
# For AVX capable systems scons build=release texture_float=yes swr_arch=avx libgl-xlib # For AVX2 capable systems scons build=release texture_float=yes swr_arch=core-avx2 libgl-xlib
Either of these will produce libGL.so* as earlier.
ParaView 5.0 Linux binaries distributed from paraview.org (including the release candidates) already package binaries for the 3 variants of Onscreen Mesa: Mesa+llvmpipe, Mesa+openswr+avx, Mesa+openswr+avx2. To launch ParaView to use any of these OpenGL implementations instead of the native OpenGL drivers, use the following:
# To use Mesa+llvmpipe ./paraview --mesa-llvm # To use Mesa+openswr-avx ./paraview --mesa-swr-avx # To use Mesa+openswr-avx2 ./paraview --mesa-swr-avx2