Paraview configuration parameters are probably wrong

[Micket]

I'm a newbie on graphics programming, but, from what I can tell:

0. Most recent easyconfigs for Paraview are probably missing some configuration parameters, I'm not sure it does any off-screen rendering at all.
1. For the off-screen rendering functionality, we should strongly prefer EGL over OSMesa. EGL can utilize GPUs if present.
2. Whether or not it can support on-screen rendering at the same time is still not sure. Whether or not we can make it work for virtualgl as the same time is ever more unsure, as it doesn't work for EGL stuff (yet).

References:

1. https://www.paraview.org/Wiki/ParaView/ParaView_And_Mesa_3D#Can_ParaView_be_built_with_X11.2FGPU_accelerated_OpenGL_and_OSMesa_in_the_same_build.3F I suspect this page is very outdated.
2. https://blog.kitware.com/off-screen-rendering-through-the-native-platform-interface-egl/ This promotes the use of EGL for off-screen, but also claims you will get a config error if you try to use EGL and VTK_USE_X=ON at the same time. That's wrong as far as I can tell.
3. https://kitware.github.io/paraview-docs/latest/cxx/Offscreen.html most up to date page i think. However, it also seems wrong or incomplete, as some mandatory parameters (e.g. EGL_LIBRARY) is actually completely ignored by cmake.

Note: When testing, pay extra attention to the warnings you may end up with at the end of the configure step. Some old documentation uses flags that are just ignored nowadays.

[Micket]

Alright so, having experimented a bit more, I think I have reached some more information (though it might be outdated).

1. With EGL support enabled, ParaView will pick a hardware device (0 by default) which mean it wont let you pick llvmpipe for software rendering. This kind of clashes with the whole idea and purpose of GLVND. Ugh. This can be overriden with
   export VTK_DEFAULT_EGL_DEVICE_INDEX=-1 if one wishes to experiment

2. Experimenting as such results in immediate crahses, as it fails with some trivial fragment shader. However, manually overriding the OpenGL version off Mesa with export MESA_GL_VERSION_OVERRIDE=3.2 it sort-of works. vtkglew still complains about some stuff, and there are some warnings, but, hey, I can at least draw something.

3. This post https://www.paraview.org/pipermail/paraview/2018-March/042227.html albeit a few years old, suggests that Paraview-EGL == Nvidia devices only. Ugh. Though, I'm not sure exaclty what would make it nvidia-only.

So.. if the post above is true, then , as far as I know;

1. Headless/offscreen rendering on GPU devices
2. Headless/offscreen rendering with software
3. Onscreen rendering with support for VirtualGL
   are all completely mutually exclusive. 3 Separate builds would be required. Yuck
   Since VirtualGL doesn't support EGL yet, this isn't all on Paraview/VTK though.

Disclaimer: It is very very very possible that I'm wrong in one, more, or possible everything here.

[Micket]

This led me down another rabbit-hole. Why the heck does glxinfo show

OpenGL renderer string: llvmpipe (LLVM 9.0.1, 256 bits)
OpenGL version string: 3.1 Mesa 20.0.2
OpenGL shading language version string: 1.40

llvmpipe has support for much newer opengl and shader language since waaay back https://mesamatrix.net/

It should be at OpenGL 3.3 - GLSL 3.30 minimum.

[mboisson]

@bartoldeman can probably provide valuable input for this.

[Micket]

So, in the future, EGL will win. VirtualGL looks to be getting some EGL support in the near future ( VirtualGL/virtualgl#10 ), but, that's not here today.

Technically, EGL should sstill suffice for all off-screen use, but, it requires setting user variables

export VTK_DEFAULT_EGL_DEVICE_INDEX=-1
export MESA_GL_VERSION_OVERRIDE=3.2

and maybe some fiddling around with libglvnd to make it use software rendering (they really just hardcode it for GPUs in VTK), so it's not super-user-friendly until that gets better support in VTK. I'm thinking about opening a issue on that to see if at least the EGL_DEVICE index part can be made more automated (if software rendering, don't pick a device, else, pick one you have right to use etc.)

So, today, building all 3 variants is probably still the way to go. We should revisit this though in the future, and get rid of the awful legacy GLX and OSMesa stuff and enter the glorious future of just EGL that works for everything

[mboisson]

Not quite sure if this is relevant, but... https://gitlab.kitware.com/paraview/paraview/-/issues/20120#note_926259

[Micket]

@lcniel fixed a fat build that covered everything, so this shouldn't be an issue anymore.