[Paraview] Segfault with OpenGL2

[Chuck Atkins]

>
> I have: Server Type = Client/Server
> Host=localhost
> Port=11772
> Command:  ssh -L 11772:remote-box:11772 user at remote-box pvserver
> --server-port=11772
>

When remotely launching a pvserver in this sort of configuration (i.e. egl
+ directly via an ssh command), a few things make this easier / more
reliable:

   - Disable OpenGL version testing.
      - This works around an issue with EGL in pvserver at the moment with
      remote rendering.
      - Use reverse port forwarding instead.
      - Basically the client listens and the server initiates a connection
      back through the tunnel.
   - Run the connection command within an xterm to be able to easily see
   pvserver output and to enter any necessary credentials via stdin (if you
   can't do key based authentication, for example).
      - Not necessary but a nice to have

Combining both of these, try the following settings:

   - Server Type = Client / Server (reverse connection)
   - Port: 11772
   - Command:

   xterm -e ssh -R 11772:localhost:11772 user at remotebox
   /path/to/install/bin/pvserver --disable-xdisplay-test --reverse-connection
   --client-host=localhost --server-port=11772



> If I set DISPLAY=:0.0 in tunneling command, I get the same error as in the
> manual setup.
>

When using EGL, there is no X server interaction so the DISPLAY variable
isn't used.



> Maybe, my compilation with EGL did not succeed?
>

Try with the above mentioned connection configuration and we'll go from
there.  I definitely suggest trying to stick with the new OpenGL back-end
if we can get the issues worked out as it's typically ~ 20x - 100x faster
for geometry rendering and 2x - 10x faster for volume rendering.

- Chuck

On Tue, Apr 12, 2016 at 1:55 PM, Harald Klimach <harald at klimachs.de> wrote:

> If I use this option via the X-server on the remote machine:
>
> > I don't have an answer to your VGL problem yet, but in the mean time,
> are you tied to having to use it that way?  If not, you also have the
> option of running ParaView in client / server mode which may actually be
> more ideal for your situation: i.e. with pvserver running on the headless
> server and the ParaView GUI client on your local machine (workstation /
> desktop / laptop, etc.) and connecting to the remote server.  Doing so, you
> can actually bypass vgl and likely get much better performance.  If you're
> running an X server on the remote machine, you can do this by setting your
> DISPLAY variable to the local x server:
> >
> > ssh foo at bigserver
> > [foo at bigserver ~]$ DISPLAY=:0.0 pvserver
> > Waiting for client...
> > Connection URL: cs://bigserver.supercooldomain.com:11111
> > Accepting connection(s): bigserver.supercooldomain.com:11111
>
> I don’t get the error message box.
> But, one thing I noticed now, is that in this case the Connection
> information in About Paraview shows me
> a different OpenGL version string in the OpenGL2 compiled pvserver than in
> the one without OpenGL2
> support.
>
> with OpenGL2 the OpenGL-Version is: 3.2.0 NVIDIA 361.28
> without, the OpenGL-Version is: 4.5.0 NVIDIA 361.28
>
> Now I am somewhat confused, as the EGL built pvserver with OpenGL2 backend
> also complained about
> OpenGL-Version 4.5.0 NVIDIA 361.28.
>
> So, with legacy OpenGL rendering backend I have 4.5.0.
> With OpenGL2, but no EGL I have 3.2.0.
> With OpenGL2 and EGL I again have 4.5.0.
>
> legacy OpenGL works via VirtualGL,
> OpenGL2 works as a pvserver using the X display on the remote machine
> without any error message boxes
> (I guess this is the option I’ll deploy now),
> OpenGL2 and EGL works as pvserver, but somehow still requires me to set
> the DISPLAY=:0.0, if I am not mistaken,
> and it has the reported error message pop-up, saying that remote rendering
> is disabled.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview/attachments/20160412/49d4a6a3/attachment.html>