In order to run VCS, a rendering environment is required on the machine on which it will be run. There are three ways to achieve a rendering environment:

• One way is to build VTK with OSMesa support. Accordingly, VCS will perform software rendering (on the CPU) instead of using the screen and any GPU driving it.
• Another approach is to require that the user who will run VCS is logged in to the machine and that this user is running a valid display. In this case, VCS will use the user's valid display environment (and the GPU) to perform its rendering.
• The third approach is to use a virtual display, such as that which is provided by a virtual network sharing (VNC) system. While the first approach requires build-time modification to VCS and the second approach may not be possible with remote servers, the third approach provides the flexibility of having a working rendering environment available for VCS installations.

The following page lists steps required to setup a remote environment using VirtualGL and TurboVNC. This is a VCS specific version of the VirtualGL documentation that goes through each step is detail.

At the highest level, the procedure for setting up VCS to render using VirtualGL and TurboVNC is as follows:

• Install, configure and test VirtualGL
• Install TurboVNC
• Use VirtualGL and TurboVNC to run VCS

Below is a summary of the instructions for installing, configuring, and testing VirtualGL. The original, complete instructions are located on the VirtualGL documentation pages.

NOTE 1 The following steps need root access to the remote server.

NOTE 2 It is recommended to install 64 bit binaries.

Download the appropriate VirtualGL binary package(s) for your system from the Files area of the VirtualGL SourceForge project page.

• For Debian systems

wget https://sourceforge.net/projects/virtualgl/files/2.5.2/virtualgl_2.5.2_amd64.deb/download -O virtualgl_2.5.2_amd64.deb

• For RPM based systems

wget https://sourceforge.net/projects/virtualgl/files/2.5.2/VirtualGL-debuginfo-2.5.2.x86_64.rpm/download -O VirtualGL-debuginfo-2.5.2.x86_64.rpm

Install the package using the system package manager as root.

For Debian systems

sudo dpkg -i virtualgl*.deb

For RM based systems

sudo rpm -e VirtualGL --allmatches
sudo yum install VirtualGL*.rpm

VirtualGL requires access to a GPU on the remote server so that it can create off-screen pixel buffers (Pbuffers) and redirect the 3D rendering from X windows into these Pbuffers. Accessing a GPU on Linux and UNIX systems requires going through an X server. This is depicted in the figure below.

The following sections explain how to configure the VirtualGL server such that selected users can run VirtualGL via the X server.

Enter TTY (hit Ctrl-Alt-F1)

sudo /etc/init.d/lightdm stop

ssh)

sudo /opt/VirtualGL/bin/vglserver_config

You will be asked three questions during this configuration. You can arrange things how you like, but for most secure configuration, you will want to reply in the affirmative to each question.

"Restrict 3D X server access to vglusers group?"  Yes.
"Restrict framebuffer device access to vglusers group?"  Yes.
"Disable XTEST extension?"  Yes.

sudo useradd vcsuser

sudo usermod -a -G vglusers vcsuser
sudo usermod -a -G vglusers root

sudo /etc/init.d/lightdm start

To verify that the remote server is ready to run VirtualGL, log out of the server, log back into the server using SSH (from a different machine) and execute the following commands in the SSH session.

• If you restricted 3D X server access to vglusers

xauth merge /etc/opt/VirtualGL/vgl_xauth_key
xdpyinfo -display :0
/opt/VirtualGL/bin/glxinfo -display :0 -c

• If you did not restrict 3D X server access

xdpyinfo -display :0
/opt/VirtualGL/bin/glxinfo -display :0 -c

Both commands should output a list of visuals and should complete without errors. If you chose to disable XTEST extension, then check the output of xdpyinfo to verity that XTEST does not show up in the list of extensions.

You should also examine the output of glxinfo to ensure that at least one of the visuals is 24-bit or 32-bit TrueColor and has Pbuffer support (the latter is indicated by a "P" in the last column.)

Example:

    visual  x   bf lv rg d st  colorbuffer  ax dp st accumbuffer  ms  cav  drw
  id dep cl sp  sz l  ci b ro  r  g  b  a F bf th cl  r  g  b  a ns b eat  typ
------------------------------------------------------------------------------
0x151 24 tc  0  32  0 r  y  .  8  8  8  0 .  4 24  8 16 16 16 16  0 0 None PXW

If none of the visuals has Pbuffer support, then this is most likely because there is no 3D acceleration, which is most likely because the correct 3D drivers are not installed (or are misconfigured). Lack of 3D acceleration is also typically indicated by the word “Mesa” in the client GLX vendor string and/or the OpenGL vendor string, and the words “Software Rasterizer” in the OpenGL renderer string.

Here is a summary of how to install TurboVNC on Linux systems. Detailed instructions can be found on the TurboVNC documentation pages.

• Download the appropriate binary package for your system from the Files area of the TurboVNC SourceForge project page.

  • For Debian systems

  wget https://sourceforge.net/projects/turbovnc/files/2.1.1/turbovnc_2.1.1_amd64.deb/download -O turbovnc_2.1.1_amd64.deb

  • For RPM based systems

  wget https://sourceforge.net/projects/turbovnc/files/2.1.1/turbovnc-2.1.1.x86_64.rpm/download -O turbovnc-2.1.1.x86_64.rpm

• Install TurboVNC

  • For Debian systems

  dpkg -i turbovnc*.deb

  • For RPM based systems

  rpm -U turbovnc*.rpm

If VirtualGL and TurboVNC have been installed and set up correctly, you can use them to provide a rendering environment for VCS. You must be logged in as the user you placed in the vglusers group on the remote server.

Start a TurboVNC session.

/opt/TurboVNC/bin/vncserver

Make a note of the X display number that the TurboVNC session is occupying. For instance:

Desktop 'TurboVNC: my_server:1 (my_user)' started on display my_server:1

You could add the -noauth argument to vncserver to allow future users to forego authentication while connecting to the session.

/opt/TurboVNC/bin/vncserver -noauth

You could also provide a display size.

/opt/TurboVNC/bin/vncserver -geometry 1440x900

as well as a custom script to be run when starting the X server.

/opt/TurboVNC/bin/vncserver -geometry 1440x900 -xstartup ~/.vnc/xstartup

For example, starting an XFCE desktop environment, the xstartup contains:

  #!/bin/sh
  unset SESSION_MANAGER
  unset DBUS_SESSION_BUS_ADDRESS
  startxfce4 &

  [ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
  [ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources

One the TurboVNC session is setup and connected to, we can run VCS applications using vglrun.

vglrun app