* Overview
{anchor: Overview}

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

With VirtualGL, the OpenGL commands and 3D data are instead redirected to a GPU
in the application server, and only the rendered frames are sent over the
network.  VirtualGL thus virtualizes GPU hardware, allowing it to be co-located
in the "cold room" with compute and storage resources.  VirtualGL also allows
GPUs to be shared among multiple users, and it provides "workstation-like"
levels of performance on 100-megabit and faster 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 Un*x OpenGL application sends all of its graphics rendering
commands and data, both 2D and 3D, to an X server, which may be located across
the network from the application server.  VirtualGL employs a technique called
"split rendering" to redirect the 3D commands and data from the OpenGL
application to a GPU in the application server.  VGL accomplishes this by
pre-loading a dynamic shared object (DSO), the VirtualGL Faker, into the OpenGL
application at run time.  The VirtualGL Faker intercepts and modifies certain
GLX, EGL, OpenGL, X11, and XCB function calls in order to divert OpenGL
rendering from the 3D application's windows into corresponding off-screen
buffers, which VGL creates in GPU memory on the application server.  When the
3D application swaps the OpenGL drawing buffers or flushes the OpenGL command
buffer to indicate that it has finished rendering a frame, VirtualGL reads back
the rendered frame from the off-screen buffer and transports it (which normally
involves delivering the frame to the 2D X server and compositing it into the 3D
application's window.)

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 X11 2D drawing commands
to the X server.  For the most part, VGL does not interfere with the delivery
of OpenGL commands to the GPU, either.  VGL merely forces the OpenGL commands
to be delivered to a GPU in the application server (through the 3D X server or
EGL device attached to the GPU) rather than to the X server to which the 2D
drawing commands are delivered (the 2D X server.)  Once the OpenGL rendering
has been redirected to an off-screen buffer, everything (including esoteric
OpenGL extensions, fragment/vertex shaders, etc.) should "just work."  If an
OpenGL application runs correctly when accessing a 3D server/workstation
locally, then the same application should run correctly with VirtualGL when
accessing the same machine remotely.

VirtualGL has two built-in "image transports" that can be used to deliver
rendered frames to the 2D X server:

{anchor: VGL_Transport}
	\1. VGL Transport :: The VGL Transport is most often used whenever the 2D X
	server is located across the network from the application server-- for
	instance, if the 2D X server is running on the client.  VirtualGL uses its
	own protocol on a dedicated TCP socket to send the rendered frames to the
	client, and the VirtualGL Client decodes the frames and composites them into
	the appropriate X window.  The VGL Transport can either deliver the frames in
	uncompressed form (RGB-encoded), or it can compress them 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 frame by the VirtualGL Client.

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

{anchor: X11_Transport}
	\2. X11 Transport :: The X11 Transport simply draws the rendered frames into
	the appropriate X window using ''XPutImage()'' or similar X11 commands.  This
	is most useful in conjunction with an X proxy, which can be one of any number
	of Un*x remote display applications, such as VNC.  When using the X11
	Transport, VirtualGL does not normally perform any image compression or
	encoding itself.  It instead relies on an X proxy to encode the frames and
	deliver them to the client(s).  Since the use of an X proxy eliminates the
	need to send X11 commands over the network, this is the recommended method
	for using VirtualGL over high-latency or low-bandwidth networks.

	!!! The XV Transport, described in {ref prefix="Chapter ": X_Video_Support},
	is a variant of the X11 Transport.

#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.
