View source for VirtualGL

{{Refimprove|date=February 2015}}
{{Infobox Software
| name                   = VirtualGL
| logo                   = 
| screenshot             = 
| caption                = 
| collapsible            = 
| author                 = 
| developer              = 
| released               = 
| latest release version = 2.6.5
| latest release date    = {{release date and age|2020|11|18}}
| latest preview version = 2.6.90 (3.0 beta1)
| latest preview date    = {{release date and age|2021|06|16}}
| frequently updated     = 
| programming language   = [[C (programming language)|C]], [[C++]], Unix Shell
| operating system       = 
| platform               = 
| size                   = 
| language               = 
| status                 = 
| genre                  = 
| license                = [[GNU General Public License]] (GPL), wxWindows Library Licence
| website                = {{URL|www.virtualgl.org}}
}}

'''VirtualGL''' ('''VGL''') is an [[open-source software|open-source]] software package that redirects the 3D rendering commands from [[Unix]] and [[Linux]] [[OpenGL]] applications to [[3D accelerator]] hardware in a dedicated server and sends the rendered output to a ([[thin client|thin]]) client located elsewhere on the network.<ref>{{cite web|url=http://www.virtualgl.org/About/Introduction|title=A Brief Introduction to VirtualGL|publisher=VirtualGL.org|access-date=20 February 2016}}</ref> On the server side, VirtualGL consists of a library that handles the redirection and a wrapper program that instructs applications to use this library. Clients can connect to the server either using a [[X Window System protocols and architecture|remote X11 connection]] or using an X11 proxy such as a [[Virtual Network Computing]] (VNC) server. In case of an X11 connection some client-side VirtualGL software is also needed to receive the rendered graphics output separately from the X11 stream. In case of a VNC connection no specific client-side software is needed other than the VNC client itself.

==Problem==
The performance of OpenGL applications can be greatly improved by rendering the graphics on dedicated hardware accelerators that are typically present in a [[Graphics processing unit|GPU]]. GPUs have become so commonplace that applications have come to rely on them for acceptable performance. But [[Virtual Network Computing|VNC]] and other thin client environments for Unix and Linux do not have access to such hardware on the server side. Therefore they either do not support [[OpenGL]] applications at all or resort to slower methods such as rendering on the client or in software on the server. 

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 [[X Window System protocols and architecture|X11 protocol stream]] 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 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 list]]s, 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 client.  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.

==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 [[Library (computing)#Dynamic_linking|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 <code>glXSwapBuffers()</code> or <code>glFinish()</code>) 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.

[[Image:X11transport.png|thumb|right|400px|When using the X11 Transport with an X proxy, both the 3D and 2D rendering occur on the application server. VirtualGL reroutes the 3D commands from the application to the 3D accelerator hardware, reads back the rendered images, and draws them as a series of uncompressed bitmaps into the X proxy (VNC or a similar system.) Meanwhile, the 2D drawing commands (X11 commands) from the application are sent to the X proxy directly. The X proxy is solely responsible for compressing the images and sending them to remote clients.]]

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 [[codec]]s to be able to handle this workload with interactive frame rates.

VirtualGL works around this problem in two ways:
# TurboVNC
# The VGL Transport

===TurboVNC and TigerVNC===
TurboVNC and [[TigerVNC]] are offshoots of [[TightVNC]] that accelerate the Tight and JPEG encoding, in part by using libjpeg-turbo, a [[SIMD]]-accelerated version of [[libjpeg]].  Both projects provide VNC servers as well as client applications.

TurboVNC was developed by the same team as VirtualGL. On [[fast Ethernet|100 Megabit Ethernet]] networks it can display more than 50 Megapixels/second with perceptually lossless image quality.  TurboVNC includes further optimizations that allow it to display 10–12 Megapixels/second over a 5 Megabit broadband link, with noticeably less but usable image quality.  TurboVNC also extends TightVNC to include client-side [[double buffering]] and other features targeted at 3D applications, such as the ability to send a lossless copy of the screen image during periods of inactivity.<ref>{{cite web|url=http://www.turbovnc.org/About/Introduction|title=A Brief Introduction to TurboVNC|publisher=TurboVNC.org|access-date=20 February 2016}}</ref>  TurboVNC and VirtualGL are used by the [[Texas Advanced Computing Center]] at [[University of Texas at Austin]] to allow users of [[TeraGrid]] to remotely access the 3D rendering capabilities of the Stampede<ref>{{cite web|url=https://portal.tacc.utexas.edu/user-guides/stampede|title=Stampede User Guide|publisher=Texas Advanced Computing Center (TACC)|access-date=29 February 2016|archive-date=10 March 2016|archive-url=https://web.archive.org/web/20160310071123/https://portal.tacc.utexas.edu/user-guides/stampede|url-status=dead}}</ref> Visualization Cluster.

TigerVNC is a more recent fork of TightVNC that provides similar performance to TurboVNC in most cases but has different project goals and features.<ref>{{cite web|url=https://wiki.archlinux.org/title/VirtualGL|title=VirtualGL|publisher=ArchLinux.org|access-date=25 June 2021}}</ref><ref>{{cite web|url=https://turbovnc.org/About/TigerVNC|title=What About TigerVNC?|publisher=The VirtualGL Project|access-date=7 Aug 2023}}</ref>


===VGL Transport===
[[Image:VGLtransport.png|thumb|right|400px|When using the VGL Transport, the 3D rendering occurs on the application server, but the 2D rendering occurs on the client machine. VirtualGL compresses the rendered images from the 3D application and sends them as a video stream to the client, which decompresses and displays the video stream in real time.]]
When using the VGL Transport, VirtualGL compresses the rendered 3D images in process using the same optimized JPEG codec that TurboVNC uses. VirtualGL then sends the compressed images over a dedicated TCP socket to a VirtualGL Client application running on the client machine. The VirtualGL Client is responsible for decompressing the images and drawing the pixels into the appropriate X window. Meanwhile, the non-OpenGL elements of the application's display are sent over the network using the standard remote X11 protocol and rendered on the client machine.

This approach requires that an X display be present on the client machine, and the reliance upon the remote X11 protocol for performing 2D rendering means that many applications will perform poorly when using the VGL Transport on high-latency networks. Additionally, the VGL Transport does not inherently support collaboration (multiple clients per session), since the images are being pushed to the users' machines rather than being pulled. But the use of the VGL Transport does provide a completely seamless application experience, whereby every application window corresponds to a single desktop window. The VGL Transport also reduces the server [[CPU]] load, since the 2D rendering is occurring on the client, and the VGL Transport allows advanced OpenGL features, such as [[Quad buffering|quad-buffered stereo]], to be used.

The developers of VirtualGL envision the primary users of the VGL Transport to be laptop users with an [[802.11g]] wireless or a fast Ethernet connection to the application server.

==Commercial products using VirtualGL==
VirtualGL and TurboVNC were core components of the [[Sun Visualization System]] product from [[Sun Microsystems]], which was discontinued in April 2009. The two open source packages were combined with a [[closed source]] plugin that allowed VirtualGL to send compressed images to [[Sun Ray]] thin clients and another closed source package that integrated VirtualGL with [[Sun Grid Engine]], providing resource management and scheduling for remote 3D jobs. The combination of these packages, dubbed "Sun Shared Visualization", was available as a free download. Sun charged for support.

v4.x.x of NoMachine supports VirtualGL to allow users to run 3D applications in NoMachine desktop sessions.<ref>{{cite web|url=https://www.nomachine.com/AR11K00737|title=Enabling VirtualGL support in NoMachine 4 or later|publisher=NoMachine.com|access-date=20 February 2016}}</ref>

v2.1 of the Scalable Visualization Array software from [[Hewlett-Packard|HP]] includes components that integrate with VirtualGL and TurboVNC, allowing 3D jobs to be scheduled on and remotely displayed from a visualization cluster.<ref>{{cite web|url=http://h20311.www2.hp.com/HPC/cache/281455-0-0-0-121.html|title=High Performance Computing (HPC)|publisher=Hp.com|access-date=17 February 2015|archive-url=https://web.archive.org/web/20140809192316/http://h20311.www2.hp.com/HPC/cache/281455-0-0-0-121.html|archive-date=9 August 2014|url-status=dead|df=dmy-all}}</ref>

v3.0.0 of [[ThinLinc]] is designed to work in conjunction with VirtualGL.<ref>{{cite web|url=https://www.cendio.com/resources/docs/tag/index.html|title=ThinLinc Administrator's Guide for ThinLinc 4.5.0 |publisher=ThinLinc.com|access-date=20 February 2016}}</ref>

v2010 of [[EnginFrame]] Views supports VirtualGL as one of the remote protocol options.<ref>{{cite web|url=http://www.nice-software.com/web/nice/remote-visualization|title=Remote Visualization|publisher=Nice-software.com|access-date=17 February 2015|archive-date=7 December 2010|archive-url=https://web.archive.org/web/20101207084716/http://www.nice-software.com/web/nice/remote-visualization|url-status=dead}}</ref>

The Exceed onDemand and Exceed Freedom products from [[OpenText]] use code from VirtualGL to implement server-side rendering.<ref>{{cite web|url=https://kb.berkeley.edu/jivekb/servlet/KbServlet/download/1715-102-192/exceed.pdf|title=Open Text Exceed User's Guide, Version 14|publisher=Kb.berkeley.edu|date=June 12, 2012|access-date=June 12, 2012|archive-date=June 15, 2010|archive-url=https://web.archive.org/web/20100615231923/https://kb.berkeley.edu/jivekb/servlet/KbServlet/download/1715-102-192/exceed.pdf|url-status=dead}}</ref>

==See also==
{{Portal|Free and open-source software}}
*[[Xgl]]
*[[AIGLX]]

==References==

===Footnotes===
{{Reflist}}

===General references===
*{{cite web|url=http://www.virtualgl.org/About/Background|title=VirtualGL Background|publisher=VirtualGL.org|access-date=20 February 2016}}
*{{cite web|url=https://cdn.rawgit.com/VirtualGL/virtualgl/2.5/doc/index.html|title=User's Guide for VirtualGL 2.5|publisher=VirtualGL.org|access-date=20 February 2016}}
*{{cite web|url=https://cdn.rawgit.com/TurboVNC/turbovnc/2.0.1/doc/index.html|title=User's Guide for TurboVNC 2.0.1|publisher=TurboVNC.org|access-date=20 February 2016}}

{{XWinSys}}

==External links==
*{{Official website|www.virtualgl.org|Official VirtualGL website}}
*{{SourceForge|virtualgl}}
*{{GitHub|VirtualGL/virtualgl|VirtualGL}}
*[http://www.turbovnc.org/ Official TurboVNC website]
*{{SourceForge|turbovnc|TurboVNC}}
*{{GitHub|TurboVNC/turbovnc|TurboVNC}}

[[Category:Free windowing systems]]
[[Category:OpenGL]]
[[Category:Remote desktop]]
[[Category:Thin clients]]