I was trying to run the Mesa version of ParaView 5.6.0-RC2 over a remote X connection.
This was possible with the Mesa version of ParaView 5.5.1, but it seems to no longer be possible
in 5.6.0-RC2. The error I am getting is vtkGenerOpenGLRenderWindow is unable to find a valid OpenGL 3.2 or later implementation. Internally the file is checking for GLEW_VERSION_3_1 or GLEW_VERSION_3_2 but it seems remote X is limited to GLEW_VERSION_3.0 and so it fails to run.
Is there a way to get a Mesa version of ParaView 5.6.0-RC2 to work over a remote X connections, or is this just no longer going to be possible?
I tried setting MESA_GL_VERSION_OVERRIDE to 3.2 and it did not work.
I searched the libGL.so produced by mesa and found that value in the file.
The error is coming from libvtkglew-pv5.6.so though that is where GLEW_VERSION_3_0
is being set to True, but higher versions such as GLEW_VERSION_3_1 and GLEW_VERSION_3_2 are
being set to false. The override does not seem to affect them and the check in
vtkOpenGLRenderWindow.cxx is still failing over remote X.
I don’t see any changes between 5.5 and 5.6 in the version of glew that ships with VTK. I thought it might have been the update to a more recent version of glew, but that change was in 5.5.
I should say I found MESA_GL_VERSION_OVERRIDE in the libGL.so produced by mesa
not is value.
I think the problem is coming from remote X which does not support OpenGL 3.2 and
libvtkglew is detecting this instead of the value set by MESA_GL_VERSION_OVERRIDE,
when determining what the OpenGL version is. It looks like libvtkglew is parsing the
name of the string returned by glGetString but that somehow this is not being set properly
using the override by libGL with remote X.
While vtkglew has not changed, what has changed though is that vtkOpenGLRenderWindow.cxx
in OpenGLInitContext() it would in 5.5.1 call this->setContextSupportsOpenGL32(true) and continue when
the check for GLEW_VERSION_3_2 or GLEW_VERSION_3_1 failed.
While in 5.6.2 does not set anything equivalent perhaps these changes in vtkOpenGLRenderWindow.cxx
are causing the change in functionality. It worked in 5.5.1 but segfaults with version 5.6.0-RC2.
I have also tried setting PV_DEBUG_SKIP_OPENGL_VERSION_CHECK with this set I get a segault,
with it not set, I get vtkXOpenGLRenderWindow.cxx line 796 failed to create offscreen window and
I get vtkOpenGLRenderWindow.cxx line 736 vtkXOpenGLRenderWindow: GLEW could not be initialized.
It would seem that vtkOpenGLRenderWindow::CreateHardwareOffScreenWindow is failing.
Perhaps, I will need to create a debug build and trace this down more thoroughly to detect
the exact failure points and values at those points. I had hoped that someone would have
already hit this issue, but perhaps they have not.
The remote system does not have hardware acceleration and is using mesa (i.e. the libGL.so built by mesa)
where mesa should be reporting OpenGL > 3.2
A local system (L) with hardware acceleration with OpenGL >= 3.2
On L, run ssh -Y [remote hostname] and then once logged on running paraview --mesa
3a) It is my understanding that the remote X protocol itself is probably the culprit, in that the
higher versions of OpenGL are not supported over remote X, and that the remote X protocol
reports that OpenGL is 3.0 instead of > 3.2 in that it is not capable of passing some of the newer
calls. Under ParaView 5.5.1 I had to use PV_DEBUG_SKIP_OPENGL_VERSION_CHECK set to 1
in order to get it to work, this no longer works for ParaView 5.6.0-RC2.
> ssh -Y vall
> tar zxvf ParaView-5.6.0-RC2-Qt5-MPI-Linux-64bit.tar.gz
> cd ParaView-5.6.0-RC2-Qt5-MPI-Linux-64bit/
> ./bin/paraview
# ---- SEGFAULT! This is using hardware accelerated
# OpenGL drivers installed on the machine
> ./bin/paraview --mesa
# --- works!
# I get a transparent opengl window -- but that's separate
# issue that will be fixed before the final release.
Can you test with the ParaView binaries to confirm that appropriate mesa build getting used please? Thanks
Here is what I found, when I use the downloaded Linux binary.
./bin/paraview
Does not segfault, but does not produce the render window either. I am getting the same errors that I got with my superbuild compiled version, where it is complaining about about the error of not finding OpenGL 3.2 or later in vtkOpenGLRenderWindow.cxx line 749, the next error is that vtkXOpenGLRenderWindow.cxx line 796 failed to create an offscreen window, followed by an error in vtkOpenGLRenderWindow.cxx on line 736 GLEW could not be initialized.
This is basically the same behavior that I am seeing with the mesa build of ParaView-RC2 built using the superbuild script, even when using the --mesa flag on the superbuild built version.
When I run the download binary version with --mesa
./bin/paraview --mesa
It works mostly. The initial renderview is corrupted, but once I add a sphere and move the mouse it starts working correctly (the corruption of the window goes away) and I can see the sphere and it does not crash.
Perhaps, their is an issue with clearing the windows initially which is causing the initial corruption of the view.
It is unclear to me, why the downloaded binary is behaving differently then the superbuild compiled binary, but it is encouraging that it is functioning better. The mesa version built by the superbuild seems to be acting as if it were the hardware accelerated version even though I am sending it the --mesa flag to it.
yes, this is indeed the issue i referenced in my post. This is separate issue and will be fixed before the final release.
Let’s dive in further. Can you do a bin/paraview -ldd on your build of ParaView with and without --mesa and see what the dependencies it finds. Is it correctly referencing Mesa GL libs built by the superbuild?
Downloaded binary version with --mesa flag
libGL.so.1 => … /Paraview-5.6.0-RC2-Qt5-MPI-Linux-64bin/lib/mesa/libGL.so.1
libGLU.so.1 => /lib64/libGLU.so.1
no entries for libGLX.so.0 or libGLdispatch.so.0
roger that…let me do a clean build from scratch and see what’s going on. BTW, where do run the paraview package from? i.e. do you do make install or cpack or directly from the build directory?
I run the superbuild build script called build_script.sh in directory call build->PV
The build script builds cmake and then runs cmake on the superbuild source to configure ParaView in a subfolder called Build_5.6.0-RC2_mesa_mpich. I have the superbuild source itself in a subfolder called Source_5.6.0 and all of the downloads reside in a subfolder Downloads (I also have the cmake tar ball there as well). I am setting the install directory pv-test->5.6.0-RC2 and then running make install to actually build everything.
Here is the folder and file structure that I am using.
So for my build, it nicely finds libGL.so from the mesa built by the superbuild when running from both build directory or installed location. let me try with your flags. can you confirm the SHA for your ParaView superbuild and that you’ve run git submodule update on the superbuild repo as well? My superbuild checkout is at “d725a65b12d5510b22311a48b36db7106bdc385a”.