VirtualGL uses "GLX forking" to perform OpenGL rendering on the application server. Unix and Linux OpenGL applications normally send both GLX commands and ordinary X11 commands to the same X display. The GLX commands are used to bind OpenGL rendering contexts to a particular X window, obtain a list of pixel formats that the X display supports, etc. VirtualGL takes advantage of a feature in Unix and Linux that allows one to "preload" a library into an application, effectively intercepting (AKA "interposing") certain function calls that the application would normally make to
shared libraries with which it is linked. Once VirtualGL is preloaded into a Unix or Linux OpenGL application, it intercepts the GLX function calls from the application and rewrites them such that the corresponding GLX commands are sent to the application server's X display (the "3D X Server"), which presumably has a 3D hardware accelerator attached. Thus, VirtualGL prevents GLX commands from being sent over the network to the user's X display or to a virtual X display ("X proxy"), such as VNC, that does not support GLX. In the process of rewriting the GLX calls, VirtualGL also redirects the OpenGL rendering into off-screen pixel buffers ("Pbuffers.") Meanwhile, the rest of the function calls from the application, including the ordinary X11 commands used to draw the application's user interface, are allowed to pass through VirtualGL without modification. Internally, VirtualGL's interposer engine also maintains a map of windows to Pbuffers, matches visual attributes between the destination X display (the "2D X Server") and the 3D X Server, and performs a variety of other hashing functions to assure that the GLX redirection is seamless. But essentially, once the OpenGL context is established on the application server's X display, VirtualGL gets out of the way and allows all subsequent OpenGL commands to pass through unimpeded to the application server's 3D hardware. Thus, the application can automatically use whatever OpenGL features and extensions are provided by the application server's hardware and drivers. Apart from marshaling GLX commands and managing Pbuffers, VirtualGL also reads back the rendered pixels at the appropriate time (usually by monitoring glXSwapBuffers() or glFinish()) and then draws those pixels into application's X window using standard X image drawing commands. Since VirtualGL is redirecting the GLX commands away from the 2D X Server, it can be used to add accelerated 3D support to X proxies (such as VNC) as well as to prevent indirect OpenGL rendering from occurring when using a remote X display. Using VirtualGL in concert with VNC or another X proxy allows multiple users to simultaneously run 3D applications on a single application server and multiple clients to share each session. However, VNC and its ilk are tuned to handle 2D applications with large areas of solid color, few colors, and few inter-frame differences. 3D applications, on the other hand, generate images with fine-grained, complex color patterns and much less correlation between subsequent frames. The workload generated by drawing rendered images from an OpenGL application into an X window is essentially the same workload as a video player, and off-the-shelf thin client software typically lacks sufficiently fast image
codecs to be able to handle this workload with interactive frame rates. VirtualGL works around this problem in two ways: • TurboVNC • The VGL Transport
TurboVNC and TigerVNC TurboVNC and
TigerVNC are offshoots of
TightVNC that accelerate the Tight and JPEG encoding, in part by using libjpeg-turbo, a
SIMD-accelerated version of
libjpeg. Both projects provide VNC servers as well as client applications. TurboVNC was developed by the same team as VirtualGL. On
100 Megabit Ethernet networks it can display more than 50 Megapixels/second with perceptually lossless image quality. TurboVNC includes further optimizations that allow it to display 10–12 Megapixels/second over a 5 Megabit broadband link, with noticeably less but usable image quality. TurboVNC also extends TightVNC to include client-side
double buffering and other features targeted at 3D applications, such as the ability to send a lossless copy of the screen image during periods of inactivity. TurboVNC and VirtualGL are used by the
Texas Advanced Computing Center at
University of Texas at Austin to allow users of
TeraGrid to remotely access the 3D rendering capabilities of the Stampede Visualization Cluster. TigerVNC is a more recent fork of TightVNC that provides similar performance to TurboVNC in most cases but has different project goals and features.
VGL Transport When using the VGL Transport, VirtualGL compresses the rendered 3D images in process using the same optimized JPEG codec that TurboVNC uses. VirtualGL then sends the compressed images over a dedicated TCP socket to a VirtualGL Client application running on the client machine. The VirtualGL Client is responsible for decompressing the images and drawing the pixels into the appropriate X window. Meanwhile, the non-OpenGL elements of the application's display are sent over the network using the standard remote X11 protocol and rendered on the client machine. This approach requires that an X display be present on the client machine, and the reliance upon the remote X11 protocol for performing 2D rendering means that many applications will perform poorly when using the VGL Transport on high-latency networks. Additionally, the VGL Transport does not inherently support collaboration (multiple clients per session), since the images are being pushed to the users' machines rather than being pulled. But the use of the VGL Transport does provide a completely seamless application experience, whereby every application window corresponds to a single desktop window. The VGL Transport also reduces the server
CPU load, since the 2D rendering is occurring on the client, and the VGL Transport allows advanced OpenGL features, such as
quad-buffered stereo, to be used. The developers of VirtualGL envision the primary users of the VGL Transport to be laptop users with an
802.11g wireless or a fast Ethernet connection to the application server. ==Commercial products using VirtualGL==