From ArchWiki
Revision as of 18:08, 15 May 2013 by Sas (talk | contribs) (flesh out usage instructions)
Jump to: navigation, search

[[Category:Networking]] [[Category:Graphics]] ***Re-enable categories when article is moved to Main namespace***

VirtualGL redirects an application's OpenGL/GLX commands to a separate X server (that has access to a 3D graphics card), captures the rendered images, and then streams them to the X server that actually handles the application.

The main use-case is to enable server-side hardware-accelerated 3D rendering for remote desktop set-ups where the X server that handles the application is either on the other side of the network (in the case of X11 forwarding), or a "virtual" X server that can't access the graphics hardware (in the case of VNC).

Installation & Setup


Using VirtualGL with X11 Forwarding


 server:                                              client:
······································               ·················
: ┌───────────┐ X11 commands         :               : ┌───────────┐ :
: │application│━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━▶│X server   │ :
: │           │        ┌───────────┐ :               : │           │ :
: │           │        │X server   │ :               : ├┈┈┈┈┈┈┈┈┈╮ │ :
: │ ╭┈┈┈┈┈┈┈┈┈┤ OpenGL │ ╭┈┈┈┈┈┈┈┈┈┤ : image stream  : │VirtualGL┊ │ :
: │ ┊VirtualGL│━━━━━━━▶│ ┊VirtualGL│━━━━━━━━━━━━━━━━━━▶│client   ┊ │ :      = "2D" rendering happens here
: └─┴─────────┘        └─┴─────────┘ :               : └─────────┴─┘ :      = "3D" rendering happens here
······································               ·················

Advantages of this set-up, compared to using VirtualGL with VNC:

  • seamless windows
  • uses a little less CPU resources on the server side
  • supports stereo rendering (for viewing with "3D glasses")


1. Preparation

In addition to setting up VirtualGL on the remote server as described above, this usage scenario requires you to:

  • install the virtualgl package on the client side as well (but no need to set it up like on the server side, we just need the vglconnect and vglclient binaries on this end).
  • set up SSH with X11 forwarding (confirm that connecting from the client to the server via ssh -X user@server and running GUI applications in the resulting shell works)

2. Connecting

Now you can use vglconnect on the client computer whenever you want to connect to the server:

$ vglconnect user@server     # X11 traffic encrypted, VGL image stream unencrypted
$ vglconnect -s user@server  # both X11 traffic and VGL image stream encrypted

This opens an SSH session with X11 forwarding just like ssh -X would, and also automatically starts the VirtualGL Client (vglclient) with the right parameters as a background daemon. This daemon will handle incoming VirtualGL image streams from the server, and will keep running in the background even after you close the SSH shell - you can stop it with vglclient -kill.

3. Running applications

Once connected, you can run remote applications with VirtualGL rendering enabled for their OpenGL parts, by starting them inside the SSH shell with vglrun:

$ vglrun glxgears

You don't need to restrict yourself to the shell that vglconnect opened for you; any ssh -X or ssh -Y shell you open from the same X session on the client to the same user@server should work. vglrun will detect that you are in an SSH shell, and make sure that the VGL image stream is sent over the network to the IP/hostname belonging to the SSH client (where the running vglclient instance will intercept and process it).

In this usage scenario, vglrun will by default compress its image stream using JPEG at 90% quality, but you can customize this using environment variables or command-line parameters, e.g.:

$ vglrun -q 30 -samp 4x glxgears  # use aggressive JPEG compression and subsampling (to reduce bandwidth demand)

Refer to vglrun -help and the user manual to learn about all available options. There is also a GUI dialog that lets you change the most common VirtualGL rendering/compression options for an application on the fly, after you have already started it with vglrun - simply press Template:Keypress while the application has keyboard focus, to open this dialog.

Using VirtualGL with VNC


 server:                                                           client:
···················································               ················
: ┌───────────┐ X11 commands         ┌──────────┐ : image stream  : ┌──────────┐ :
: │application│━━━━━━━━━━━━━━━━━━━━━▶│VNC server│━━━━━━━━━━━━━━━━━━▶│VNC viewer│ :
: │           │        ┌───────────┐ └──────────┘ :               : └──────────┘ :
: │           │        │X server   │        ▲     :               :              :
: │ ╭┈┈┈┈┈┈┈┈┈┤ OpenGL │ ╭┈┈┈┈┈┈┈┈┈┤ images ┃     :               :              :
: │ ┊VirtualGL│━━━━━━━▶│ ┊VirtualGL│━━━━━━━━┛     :               :              :      = "2D" rendering happens here
: └─┴─────────┘        └─┴─────────┘              :               :              :      = "3D" rendering happens here
···················································               ················

Advantages of this set-up, compared to using VirtualGL with X11 Forwarding:

  • can maintain better performance in case of low-bandwidth/high-latency networks
  • can send the same image stream to multiple clients ("desktop sharing")
  • the remote application can continue running even when the network connection drops
  • better support for non-Linux clients, as the architecture does not depend on a client-side X server


After setting up VirtualGL on the remote server as described above, and establishing a working remote desktop connection using the VNC client/server implementation of your choice, no further configuration should be needed.

Inside the VNC session (e.g. in a terminal emulator within the VNC desktop or even directly in ~/.vnc/xstartup), simply run selected applications with vglrun in order to activate VirtualGL rendering for their OpenGL parts:

$ vglrun glxgears

Note that in this usage scenario, many of vglrun's command-line options (e.g. those relating to image stream compression or stereo rendering) are not applicable, because there is no vglclient daemon running on the other end - the raw images are sent directly (through the normal X11 protocol) to the VNC server, which is running on the same machine. It is now the VNC server that handles all the image stream optimization/compression, so it is there that you should turn to for fine-tuning.

Choosing an approriate VNC package

VirtualGL can provide 3D rendering for any general-purpose vncserver implementation (e.g. TightVNC, RealVNC, ...).
However, if you want to really get good performance out of it (e.g. to make it viable to watch videos or play OpenGL games over VNC), you might want to use one of the VNC implementations that are specifically optimized for this use-case:

  • TurboVNC: Developed by the same team as VirtualGL, with the explicit goal of providing the best possible performance in combination with it.
  • TigerVNC: Also developed with VirtualGL in mind and achieves good performance with it, while providing better Xorg compatibility than TurboVNC.



See Also