[[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 applications just like in any other X11-forwarding enabled SSH shell. In order to activate VirtualGL rendering for the OpenGL parts of an application, though, you need to run it with
$ vglrun glxgears
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
$ vglrun glxgears
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 impementations 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.
- VirtualGL Online Documentation (you can also find it at
/usr/share/doc/virtualgl/index.htmlif you have installed)