VirtualGL

VirtualGL is an open source program that redirects the 3D rendering commands from Unix and Linux OpenGL applications to 3D accelerator hardware in a dedicated server and displays the rendered output interactively to a thin client located elsewhere on the network.

Normally, VNC and other thin client environments for Unix and Linux either do not support running OpenGL applications at all or force the OpenGL applications to be rendered without the benefit of OpenGL hardware acceleration. Remotely displaying 3D applications with hardware acceleration has traditionally required the use of "indirect rendering." Indirect rendering uses the GLX extension to the X Window System ("X11" or "X") to encapsulate the OpenGL commands inside of the and ship them from an application to an X display. Traditionally, the application runs on a remotely located application server, and the X display runs on the user's desktop. In this scenario, all of the OpenGL commands are executed by the user's desktop machine, so that machine must have a fast 3D graphics accelerator. This limits the type of machine that can remotely display a 3D application using this method.

Indirect rendering can be shown to perform well if the network is sufficiently fast (Gigabit Ethernet, for instance), if the application does not dynamically modify the geometry of the object being rendered, if the application uses display lists, and if the application does not use a great deal of texture mapping. Many OpenGL applications, however, do not meet these criteria. To further complicate matters, some OpenGL extensions do not work in an indirect rendering environment. Some of these extensions require the ability to directly access the 3D graphics hardware and thus can never be made to work indirectly. In other cases, the user's X display may not provide explicit support for a needed OpenGL extension, or the extension may rely on a specific hardware configuration that is not present on the user's desktop machine.

Performing OpenGL rendering on the application server circumvents the issues introduced by indirect rendering, since the application now has a fast and direct path to the 3D rendering hardware. If the 3D rendering occurs on the application server, then only the resulting 2D images must be sent to the user's desktop. Images can be delivered at the same frame rate regardless of how big the 3D data was that was used to generate them, so performing 3D rendering on the application server effectively converts the 3D performance problem into a 2D performance problem. The problem then becomes how to stream 1-2 megapixels of image data over a network at interactive frame rates, but commodity technologies (HDTV, to name one) already address this problem.