Virtual GL - VirtualGL's Solution

VirtualGL's Solution

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:

1. TurboVNC
2. The VGL Transport