Using Slicer via VNC + VirtualGL

Support
1

I’m trying to access Slicer installed on a server through tigervnc client. But I get the following error

[user@server ~]$ vglrun glxgears
No protocol specified
Error: couldn't open display :0
[user@server ~]$ vncserver -list

TigerVNC server sessions:

X DISPLAY #     PROCESS ID
:1              10902
:5              14662
[user@server ~]$ export DISPLAY=:1
[user@server ~]$ cd Slicer-4.11.0-2020-05-19-linux-amd64/
[user@server Slicer-4.11.0-2020-05-19-linux-amd64]$ vglrun ./Slicer
No protocol specified
[VGL] ERROR: Could not open display :0.
vtkDebugLeaks has found no leaks.

I’ve used export DISPLAY=:1 and I still get [VGL] ERROR: Could not open display :0.
Any help?

2

I think the first command shows that either

  1. There is no X0 session running or
  2. VirtualGL is not configured correctly.

Particularly did you run the vglserver_config after installtin the VGL? If so, did you restricted the framebuffer access to vglusers (which is default). You may have to add your user to vglusers groups.

Follow the specific instructions for correctly configuring the server here:
https://cdn.rawgit.com/VirtualGL/virtualgl/2.6.3/doc/index.html#hd006

If you can’t get glxgears working, it is unlikely that Slicer would work.

1 Like
3

Thank you.

I didn’t add the display flag last time. After adding the display flag I get,

I think the issue that currently occurs is due to the above reason that you mentioned
vglrun -d :1 glxgears
[VGL] NOTICE: Automatically setting VGL_CLIENT environment variable to
[VGL] xx.x.x.xx, the IP address of your SSH client.
failed to create drawable
[VGL] ERROR: in OGLDrawable–
[VGL] 82: Could not create Pbuffer

4

If you are remoting into your session via vnc directly, you really don’t need to set the display parameter.
To me error still tell me that the user is not part of the vglusers group, and VGL doesn’t have permission to access the framebuffer.

if you say

> id $USER

do you see vglusers group listed in the output, otherwise it won’t work.

6

from error: GLSL 1.50 is not supported - #4 by pieper helped.

Unfortunately, even after changing the VGL permission settings to allow all users, VGL didn’t work for me.

Thanks for the support

1 Like
7

Did you achieve VGL working for Slicer?

8

Yes, I think MESA_GL_VERSION_OVERRIDE=3.2 ./Slicer worked for me.

9

Correctly setup VGL shouldn’t require this override, since it should provide a opengl version that’s compatible with Slicer e.g.,

maga@magalab-ML:~/Downloads$ vglrun /opt/VirtualGL/bin/glxinfo |more
name of display: :1.0
display: :1  screen: 0
direct rendering: Yes
server glx vendor string: VirtualGL
server glx version string: 1.4
server glx extensions:
    GLX_ARB_create_context, GLX_ARB_create_context_profile, 
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_swap_control, 
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, 
    GLX_SGIX_pbuffer, GLX_SGI_make_current_read, GLX_SGI_swap_control
client glx vendor string: VirtualGL
client glx version string: 1.4
client glx extensions:
    GLX_ARB_create_context, GLX_ARB_create_context_profile, 
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_swap_control, 
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, 
    GLX_SGIX_pbuffer, GLX_SGI_make_current_read, GLX_SGI_swap_control
GLX version: 1.4
GLX extensions:
    GLX_ARB_create_context, GLX_ARB_create_context_profile, 
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_swap_control, 
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, 
    GLX_SGIX_pbuffer, GLX_SGI_make_current_read, GLX_SGI_swap_control
Memory info (GL_NVX_gpu_memory_info):
    Dedicated video memory: 8192 MB
    Total available memory: 8192 MB
    Currently available dedicated video memory: 7356 MB
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: Quadro RTX 4000/PCIe/SSE2
OpenGL core profile version string: 4.6.0 NVIDIA 470.82.01
OpenGL core profile shading language version string: 4.60 NVIDIA
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
10

I’ve made it work. I’ll share details on a few days

11

Good to hear. We have been using VGL for a while, almost never had any installation/configuration issues for vanilla centos or ubuntu. Love to hear your use case.

12

Our team started from this repository some months ago.

But we wanted not to execute a window manager on our environment.

The TurboVNC manual tells you how to do this here:

Procedure

  1. Follow the procedure described in Chapter 6 for starting a TurboVNC session and connecting to it.
  2. Open a new terminal inside the TurboVNC desktop.
  3. In the terminal, start a 3D application using VirtualGL:
    /opt/VirtualGL/bin/vglrun [vglrun options] 3D-application-executable-or-script [arguments]

So, supposing we have achieved 1.
We just need to do 2. and 3.

  1. can be translated by unix convention to prefixing the contents of the next line to the code on 3.
    DISPLAY=$VNCDISPLAY sh

So with 3. (leaving default options) our total command is:
DISPLAY=$VNCDISPLAY sh /opt/VirtualGL/bin/vglrun path/to/slicer/Slicer

But that doesn’t work, at least on our configuration.

Searching the error code on the VirtualGL issues solves this, according to dcommander:

eglinfo accesses the DRI devices in the same way that VirtualGL does, so if eglinfo egl works, that suggests that VGL_DEVICE=egl should work. As to why the specific DRI devices don’t work, I have no idea. Perhaps the user account does not have appropriate permissions for the matching /dev/dri/render * devices? Did you run vglserver_config in the container?

The key here is that VGL_DEVICE=egl should work.

That means setting the option -d egl on vglrun according to its help-text.

So our corrected command is:
DISPLAY=$VNCDISPLAY sh /opt/VirtualGL/bin/vglrun -d egl path/to/slicer/Slicer

And it correctly works.

2 Likes