* Using VirtualGL in a Sun Ray Environment
{anchor: Sun_Ray_Usage}

The Sun Ray technology from Oracle consists of a software component
(the Sun Ray Server Software, or SRSS) and an ultra-thin hardware client (the
Sun Ray Desktop Unit, or DTU.)  The SRSS receives connection requests from
multiple DTU's and creates a separate instance of the Sun Ray X Server (an
X proxy) for each user.  These X proxy sessions can be seamlessly
suspended/resumed or migrated from one DTU to another by the use of smartcards
(every Sun Ray DTU has a built-in smartcard reader.)

As with most X proxies, each instance of the Sun Ray X Server creates a virtual
desktop with which the user can interact to launch applications.  The Sun Ray X
Server is responsible for compressing the images from the virtual desktop and
sending the compressed images across the network to the user's DTU using the
proprietary ALP protocol.  The images are converted to YUV with up to 16X
chrominance subsampling and can be further compressed using Differential Pulse
Code Modulation (DPCM) or wavelets.

If VirtualGL is installed and run on a Sun Ray Server, then the 3D images from
VirtualGL can be displayed to a Sun Ray X Server instance using the X11
Transport, as with any other X proxy.  However, most Sun Ray Servers are
deployed as 2D application servers, and thus they may have dozens of users
connecting to them at any given time.  3D applications are very demanding of
system resources, so running these applications on a Sun Ray Server that is
shared by many 2D application users is not a recommended approach.

To get around this problem, VirtualGL 2.0.x and 2.1.x used a proprietary plugin
provided by Sun, which sent images directly from the 3D application server
to the Sun Ray DTU, thus bypassing the Sun Ray Server altogether.

#IMG: sunray.png
#CAP: The Sun Ray Transport (Provided by a Proprietary Plugin to VirtualGL 2.0.x and 2.1.x)

When the Sun Visualization System product was discontinued in early 2009, the
proprietary VirtualGL Sun Ray plugin was discontinued along with it.  Although
sending pre-compressed images directly to the DTU was advantageous in that it
eliminated almost all of the CPU and network load from the Sun Ray Server, it
was not without its problems.  Handling window clipping and throttling the
bandwidth to avoid dropped UDP packets were among these.  With the release
of SRSS 4.1, Sun implemented the X Video extension in the Sun Ray X Server,
which allows applications to pre-encode YUV images and send these through
the Sun Ray X Server to the DTU without any transcoding.

VirtualGL 2.2 supports this mechanism through the use of the XV Transport and
the VGL Transport with YUV encoding (see
{ref prefix="Chapter ": X_Video_Support}.)  If VirtualGL detects that the 2D X
server is a Sun Ray X Server instance, then it will automatically enable the XV
Transport if the X server connection is local or the VGL Transport with YUV
encoding if the X server is remote.  The remote case is illustrated in the
figure below.

#IMG: sunrayvgltransport.png
#CAP: The VGL Transport with YUV Encoding in a Sun Ray Environment

There are trade-offs with using X Video vs. using the Sun Ray Transport.
Whereas the X Video mechanism still uses very little CPU time on the Sun Ray
Server, it requires a great deal of network bandwidth.  The Sun Ray X Video
implementation only supports up to 4X chrominance subsampling, which means that
a 2:1 compression ratio is the best that one can achieve.  This means that each
pixel sent through the Sun Ray server will require approximately 24 bits to
represent it on the network (12 bits coming in from the 3D server, and another
12 going out to the Sun Ray DTU.)  To sustain a 1280x1024 image stream at 8
frames/second (generally the maximum sustainable performance for that size
image on Sun Ray 2 hardware) would require 250 Megabits/second of bandwidth.
In general, the Sun Ray Server would need to be provisioned with multiple
Gigabit Ethernet adapters in this case.
