[[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")
In addition to setting up VirtualGL on the remote server as described above, this usage scenario requires you to:
- install the
vglclientbinaries on this end).
package on the client side as well (but no need to set it up like on the server side, we just need the
- set up SSH with X11 forwarding (confirm that connecting from the client to the server via
ssh -X user@serverand running GUI applications in the resulting shell works)
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
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 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)
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.
Tips & Tricks
Confirming that VirtualGL rendering is active
If you set the
VGL_LOGO environment variable before starting an application with
vglrun, a small logo reading "VGL" will be shown in the bottom-right corner of any OpenGL scene that is rendered through VirtualGL in that application:
$ VGL_LOGO=1 vglrun glxgears
- VirtualGL Online Documentation (you can also find it at
/usr/share/doc/virtualgl/index.htmlif you have installed)