Messing with Mesa for ParaView 5.0/VTK 7.0

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:

 

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.

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:

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:

8 Responses to Messing with Mesa for ParaView 5.0/VTK 7.0

  1. Chrishas says:

    Thanks for this very informative post.
    Can you explain how you compile Paraview with llvmpipe in a bit more detail? I tried Mesa 11.2.2 but I get errors such as:

    CMakeFiles/vtkRenderingOpenGL.dir/vtkOpenGLExtensionManager.cxx.o: In function vtkOpenGLExtensionManager::GetProcAddress(char con
    st*)':
    /home/chris/ParaView-v5.0.1-source/VTK/Rendering/OpenGL/vtkOpenGLExtensionManager.cxx:725: undefined reference to
    OSMesaGetProcAddress’

    Also since Paraview with Mesa only builds the command line programs can a separate Paraview installation with the gui connect to the off-rendering pvservers?

    Thanks,

    Chris

  2. Utkarsh Ayachit says:

    Chris, looks like you’re using older OpenGL rendering backend. I’d suggest setting VTK_RENDERING_BACKEND CMake flag to OpenGL2 and trying again. Do you still get the same build error?

    • Chrishas says:

      Utkarsh thanks for the hint, unfortunately I get another issue:

      CMakeFiles/vtkglew.dir/src/glew.c.o: In function _glewGetExtensions':
      glew.c:(.text+0x2423a): undefined reference to
      glGetIntegerv’
      glew.c:(.text+0x24328): undefined reference to glGetString'
      CMakeFiles/vtkglew.dir/src/glew.c.o: In function
      glewContextInit’:
      glew.c:(.text+0x243a2): undefined reference to glGetString'
      collect2: error: ld returned 1 exit status
      make[2]: *** [lib/libvtkglew-pv5.0.so.1] Error 1
      make[1]: *** [VTK/ThirdParty/glew/vtkglew/CMakeFiles/vtkglew.dir/all] Error 2
      make[1]: *** Waiting for unfinished jobs....
      make: *** [all] Error 2

      The cmake command:

      cmake .. -DCMAKE_INSTALL_PREFIX=$INSTALL_DIR \
      -DCMAKE_C_COMPILER:FILEPATH=$(which gcc) \
      -DCMAKE_CXX_COMPILER:FILEPATH=$(which g++) \
      -DBoost_NO_BOOST_CMAKE:BOOL=ON \
      -DBUILD_TESTING:BOOL=OFF \
      -DCMAKE_PREFIX_PATH:PATH=$QT_DIR \
      -DICET_BUILD_TESTING:BOOL=OFF \
      -DVTK_USE_X:BOOL=OFF \
      -DPARAVIEW_BUILD_QT_GUI=OFF \
      -DPARAVIEW_ENABLE_PYTHON=yes \
      -DPARAVIEW_ENABLE_XDMF3=yes \
      -DPARAVIEW_USE_MPI=yes \
      -DPARAVIEW_USE_VISITBRIDGE=no \
      -DVTK_OPENGL_HAS_OSMESA=ON \
      -DVTK_RENDERING_BACKEND=OpenGL2 \
      -DOPENGL_INCLUDE_DIR:PATH=$MESA_DIR/include \
      -DOPENGL_gl_LIBRARY:FILEPATH=$MESA_DIR/lib/libosmesa.so \
      -DOPENGL_glu_LIBRARY:FILEPATH=$GLU_DIR/lib/libGLU.so \
      -DOSMESA_INCLUDE_DIR:PATH=$MESA_DIR/include \
      -DOSMESA_LIBRARY:FILEPATH=$MESA_DIR/lib/libosmesa.so

      If I change libosmesa.so to libGL.so then compilation goes up to 51% and I get errors like:
      ParaView-v5.0.1-source/VTK/Rendering/OpenGL2/vtkOSOpenGLRenderWindow.cxx:195: undefined reference to
      OSMesaGetProcAddress’
      ParaView-v5.0.1-source/VTK/Rendering/OpenGL2/vtkOSOpenGLRenderWindow.cxx:205: undefined reference to OSMesaCreateContext'
      CMakeFiles/vtkRenderingOpenGL2.dir/vtkOSOpenGLRenderWindow.cxx.o: In function
      vtkOSOpenGLRenderWindow::DestroyOffScreenWindow()’:
      /ParaView-v5.0.1-source/VTK/Rendering/OpenGL2/vtkOSOpenGLRenderWindow.cxx:245: undefined reference to `OSMesaDestroyContext’

      • Utkarsh Ayachit says:

        Try using the following

        -DOPENGL_INCLUDE_DIR:PATH=
        -DOPENGL_xmesa_INCLUDE_DIR:PATH=
        -DOPENGL_gl_LIBRARY:FILEPATH=
        -DOPENGL_glu_LIBRARY:FILEPATH=
        -DOSMESA_INCLUDE_DIR:PATH=$MESA_DIR/include
        -DOSMESA_LIBRARY:FILEPATH=$MESA_DIR/lib/${OSMESALIB}

        I am working on updating ParaView’s superbuild to build OSMesa 11.2.2 and didn’t have any problems — atleast on my build.

        Here’s the MR in case you’re interested: https://gitlab.kitware.com/paraview/paraview-superbuild/merge_requests/114/diffs

  3. fahad says:

    HI Utkarsh Ayachit:

    Probably off topic but it would greatly help me if you could tell me which version of paraview works fine with the openGL3.1 on windows? There is no guidance on it. I had downloaded version 5.0.1 but it says use older versions compatible with opengl3.1. Thanks

    • Utkarsh Ayachit says:

      Use ParaVew 4.4 or earlier if you your OpenGL drivers don’t support OpenGL 3.1 or later.

  4. Lily says:

    I’m trying to build a standalone VTK, but I’m not sure how to change VTK configuration to use Mesa and not OpenGL

    Thanks!

  5. Utkarsh Ayachit says:

    @Lily, where is your Mesa coming from? Just to use Mesa instead of hardware OpenGL, I often just set by LD_LIBRARY_PATH to the dir containing the libGL.* from Mesa and then run ParaView/VTK. That’d work.

Questions or comments are always welcome!