3

I'm running OpenFOAM on a remote server and basically manage to visualize the results via paraview's pvserver as described here. However upon connection the client yields

Server DISPLAY not accessible!

Display is not accessible on the server side. Remote rendering will be disabled.

which is basically correct, since the server doesn't run an X server. Performance is of course suboptimal since without remote rendering the entire geometry is transferred (I guess it's almost as bad as directly ssh-copying the files to run purely locally). The server does have a simple onboard GPU (c2:00.0 VGA compatible controller: ASPEED Technology, Inc. ASPEED Graphics Family (rev 41) as per lspci), using which might be called plan B since at some point I might switch to a server without GPU or an entirely different one. So instead, I had a look at https://kitware.github.io/paraview-docs/latest/cxx/Offscreen.html, and using Arch Linux I obtained its paraview PKGBUILD via asp checkout paraview and appended the following switches to its build() -> cmake instruction:

        -DVTK_OPENGL_HAS_OSMESA=ON \
        -DVTK_USE_X=OFF \
        -DPARAVIEW_USE_QT=OFF \

Compilation went without errors (though lots of warnings which I might have to check if they are different with and without those switches), yet pvserver now SEGFAULTs:

$LD_PRELOAD=/usrlib/libGLEW.so pvserver --force-offscreen-rendering
Waiting for client...
Connection URL: cs://xxx:11111
Accepting connection(s): xxx:11111
Client connected.
(  52.668s) [pvserver        ]vtkOpenGLRenderWindow.c:565    ERR| vtkOSOpenGLRenderWindow (0x55f0fa7f4b60): GLEW could not be initialized: Missing GL version

Loguru caught a signal: SIGSEGV
Stack trace:
0       0x7f53ca2c8f80 /usr/bin/../lib/libc.so.6(+0x3cf80) [0x7f53ca2c8f80]
(  52.669s) [pvserver        ]                       :0     FATL| Signal: SIGSEGV
Segmentation fault (core dumped)

LD_PRELOADing the existing libGLEW.so as suggested e.g. here did not change things so now I'm stuck... /usr/lib/libosmesa.so is also present, as is libOpenGL.so, so what am I missing? How can I troubleshoot this properly?

Tobias Kienzler
  • 25,759
  • 22
  • 127
  • 221
  • The correct doc is available here: https://kitware.github.io/paraview-docs/v5.9.0/cxx/Offscreen.html your build should be fonctionnal though. – Mathieu Westphal Mar 05 '21 at 09:30
  • @MathieuWestphal Oh thanks! Hm, so is this more of a problem with my mesa installation then? I'm afraid I don't know how to climb further down this rabbit hole... – Tobias Kienzler Mar 05 '21 at 09:48
  • why do you preload libGLEW ? – Mathieu Westphal Mar 08 '21 at 10:53
  • @MathieuWestphal It's just a fix suggested at https://github.com/openai/mujoco-py/issues/268#issuecomment-595177264, but doesn't change the result either way – Tobias Kienzler Mar 08 '21 at 11:49
  • Ok. All I can tell you is that specific setup works perfectly here. How did you build/install osmesa ? – Mathieu Westphal Mar 09 '21 at 10:43
  • @MathieuWestphal [`libOSMesa.so` is part of the `extra/mesa`](https://archlinux.org/packages/extra/x86_64/mesa/) package on Arch (or more precisely Manjaro) Linux. I'm maybe a bit lost in X server stuff - does the server need any instance of Xorg e.g.? But I guess I should ask that separately on unix.SE... – Tobias Kienzler Mar 10 '21 at 11:03
  • I'm using ArchLinux as well, see my answer. – Mathieu Westphal Mar 10 '21 at 17:14

1 Answers1

5

I'm using ArchLinux and the folowing is working perfectly:

git clone https://gitlab.kitware.com/paraview/paraview.git --recursive
mkdir build
cd build
cmake -GNinja -DVTK_OPENGL_HAS_OSMESA=ON  -DVTK_USE_X=OFF -DPARAVIEW_USE_QT=OFF ../paraview
ninja
./bin/pvserver

then connecting from an actual ParaView and rendering something on the server works perfectly.

Mathieu Westphal
  • 2,544
  • 1
  • 19
  • 33
  • Oh great, I'll give this a shot, thank you :) – Tobias Kienzler Mar 11 '21 at 15:00
  • 1
    It works, thank you very much! I'll try and create an adequate `PKGBUILD` file later on. Note to self since I'm still using 5.8.1: `git worktree add v5.8.1 v5.8.1; cd v5.8.1; git submodule update --init --recursive` (of course instead of `worktree` a detached `checkout` would work just as well) – Tobias Kienzler Mar 11 '21 at 16:09
  • Are there any prerequisites? Following these steps on Ubuntu 20.04, `cmake` failed with "Could not find the OSMesa external dependency". – Roger Dueck Jun 18 '21 at 15:20
  • install osmesa I suppose ? – Mathieu Westphal Jun 18 '21 at 20:27