glGenFramebuffers errors in pvserver 5.8

ParaView Support
1

I usually compile pvserver on our CPU cluster with the following flags:

-DVTK_OPENGL_HAS_OSMESA=ON
-DPARAVIEW_USE_MPI=ON -DBUILD_TESTING=OFF
-DVTK_USE_X=OFF -DPARAVIEW_BUILD_QT_GUI=OFF
-DPARAVIEW_ENABLE_PYTHON=ON
-DPARAVIEW_BUILD_SHARED_LIBS=ON

With 5.7 and earlier versions, I had no problems establishing client-server connections and doing offscreen rendering.

With 5.8, right after establishing a client-server connection (using 5.8 client), I receive the following message:

Accepting connection(s): …:11111
Client connected.
(15.960s) [pvserver]vtkOpenGLFramebufferObj:356 ERR| vtkOpenGLFramebufferObject (0x237b230): failed at glGenFramebuffers 1 OpenGL errors detected
0 : (1280) Invalid enum

Any idea of what might be wrong?

I just tried recompiling pvserver 5.7 and there are no issues, only with 5.8. No configuration or compilation errors in either case.

Thanks.

2

@cory.quammen : this one may be important.

3

The OpenGL error must be before the call to glGenFramebuffers because that call can’t cause an invalid enum error.

@razoumov could you quickly try the osmesa packages we provide on paraview.org and see if you can reproduce the error with that binary? www.paraview.org/download and look under the heading “ParaView Server for Headless Machines”. Thanks.

4

Thanks, @cory.quammen ! The precompiled headless pvserver works without this error, but is very slow (starting the server, handshaking, loading a small dataset). I also tried a custom-compiled 5.7.1 pvserver in the same interactive job, and it is fast. We really need to figure out these glGenFramebuffers errors. Was there anything in the source that required a more recent OSMesa?

5

We are using Mesa 18.2.2 FWIW. I’m not sure what the minimum required is. Can you build against that version and see if the error message persists?

6

Switching to Mesa 19.2.7 solved the issue. Thank you for your help!

1 Like
7

Great, thanks for the followup.

8

Do we mention a minimum mesa version somewhere ? We should.

9

We do not have a separate document that lists minimum third-party libraries required by ParaView or VTK. Frankly, we don’t have the time to figure out what the minimum version required is. Working version is known, and is implicit in the import commits for third-party libraries or in the versions.cmake file in ParaView’s superbuild. A separate document will never be kept up to date with the code due to human tendency to forget to update such a document, unfortunately.

10

fair enough. Then how should one figure out the used version of mesa ?

11

Consult https://gitlab.kitware.com/paraview/paraview-superbuild/blob/master/versions.cmake.

12

Indeed ! Thanks @cory.quammen !

13

How serious are those glGenFramebuffers errors? One of our users is seeing these as well in PV 5.8.0 with OSmesa support (Mesa 18.3.6), but he does get rendered output. Before I embark on trying Mesa 19.2.7 as above (which will be fun as they switched build systems to Meson) I’d like to ask an opinion if that is worth the trouble?

14

If rendering is fine, then the error messages are not important. They can become a problem if repeated with every render on hundreds or thousands of processes, though, as reporting the errors will consume a lot of CPU time and network transfer.

15

If I remember correctly, after getting the glGenFramebuffers error my client-server connection drops.