* Overview
{anchor: Overview}

VirtualGL is an open source package that gives any Unix or Linux remote
display software the ability to run OpenGL applications with full 3D
hardware acceleration.  Some remote display software lacks the ability to run
OpenGL applications at all.  Other remote display software forces OpenGL
applications to use a slow software-only OpenGL renderer, to the detriment of
performance as well as compatibility.  The traditional method of displaying
OpenGL applications to a remote X server (indirect rendering) supports 3D
hardware acceleration, but this approach causes all of the OpenGL commands and
3D data to be sent over the network to be rendered on the client machine.  This
is not a tenable proposition unless the data is relatively small and static,
unless the network is very fast, and unless the OpenGL application is
specifically tuned for a remote X-Windows environment.

With VirtualGL, the OpenGL commands and 3D data are instead redirected to a
3D graphics accelerator on the application server, and only the rendered 3D
images are sent to the client machine.  VirtualGL thus "virtualizes" 3D
graphics hardware, allowing it to be co-located in the "cold room" with compute
and storage resources.  VirtualGL also allows 3D graphics hardware to be shared
among multiple users, and it provides "workstation-like" levels of performance
on even the most modest of networks.  This makes it possible for large, noisy,
hot 3D workstations to be replaced with laptops or even thinner clients.  More
importantly, however, VirtualGL eliminates the workstation and the network as
barriers to data size.  Users can now visualize huge amounts of data
in real time without needing to copy any of the data over the network or sit in
front of the machine that is rendering the data.

Normally, a Unix OpenGL application would send all of its drawing commands
and data, both 2D and 3D, to an X-Windows server, which may be located across
the network from the application server.  VirtualGL, however, employs a
technique called "split rendering" to force the 3D commands from the
application to go to a 3D graphics card in the application server.  VGL
accomplishes this by pre-loading a dynamic shared object (DSO) into the
OpenGL application at run time.  This DSO intercepts a handful of GLX, OpenGL,
and X11 commands necessary to perform split rendering.  Whenever a window is
created by the application, VirtualGL creates a corresponding 3D pixel buffer
("Pbuffer") on a 3D graphics card in the application server.  Whenever the
application requests that an OpenGL rendering context be created for the
window, VirtualGL intercepts the request and creates the context on the
corresponding Pbuffer instead.  Whenever the  application swaps or flushes the
drawing buffer to indicate that it has finished rendering a frame, VirtualGL
reads back the Pbuffer and sends the rendered 3D image to the client.

The beauty of this approach is its non-intrusiveness.  VirtualGL monitors a
few X11 commands and events to determine when windows have been resized, etc.,
but it does not interfere in any way with the delivery of 2D X11 commands to
the X server.  For the most part, VGL does not interfere with the delivery of
OpenGL commands to the graphics card, either (there are some exceptions, such
as its handling of color index rendering.)  VGL merely forces the OpenGL
commands to be delivered to a server-side graphics card rather than a
client-side graphics card.  Once the OpenGL rendering context has been
established in a server-side Pbuffer, everything (including esoteric OpenGL
extensions, fragment/vertex programs, etc.) should "just work."  If an
application runs locally on a 3D server/workstation, then that same application
should run remotely from that same machine using VirtualGL.

VirtualGL has two built-in "image transports" that can be used to send
rendered 3D images to the client machine:

{anchor: VGL_Transport}
	\1. VGL Transport :: The VGL Transport is most often used whenever the 2D X
	server (the X server used to draw the application's GUI and transmit keyboard
	and mouse events back to the application server) is located across the
	network from the application server, for instance if the 2D X server is
	running on the user's desktop machine.  VirtualGL uses its own protocol on a
	dedicated TCP socket to send the rendered 3D images to the client machine,
	and the VirtualGL Client application decodes the images and composites them
	into the appropriate X window.  The VGL Transport can either deliver
	uncompressed images (RGB encoded), or it can compress images in real time
	using a high-speed JPEG codec.  It also supports the delivery of stereo image
	pairs, which can be reconstructed into a stereo image by the VirtualGL
	Client.

#IMG: vgltransport.png
#CAP: The VGL Transport with a Remote 2D X Server

{anchor: X11_Transport}
	\2. X11 Transport :: The X11 Transport simply draws the rendered 3D images
	into the appropriate X window using XPutImage() and similar X-Windows
	commands.  This is most useful in conjunction with an "X Proxy", which can be
	one of any number of Unix remote display applications, such as VNC.  These X
	proxies are essentially "virtual" X servers.  They appear to the application
	as a normal X server, but they perform X11 rendering to a virtual framebuffer
	in main memory rather than to a real framebuffer on a graphics card.  This
	allows the X proxy to send only images to the client machine rather than
	chatty X-Windows rendering commands.  When using the X11 Transport, VirtualGL
	does not perform any image compression or encoding itself.  It instead relies
	upon an X proxy to encode and deliver the images to the client(s).  Since the
	use of an X proxy eliminates the need to send X-Windows commands over the
	network, this is the best means of using VirtualGL over high-latency or
	low-bandwidth networks.

#IMG: x11transport.png
#CAP: The X11 Transport with an X Proxy

VirtualGL also provides an API that can be used to develop custom image
transport plugins.
