VirtualGL

VirtualGL ( VGL ) es un paquete de software de código abierto que redirige los comandos de renderizado 3D de aplicaciones OpenGL de Unix y Linux a hardware acelerador 3D en un servidor dedicado y envía la salida renderizada a un cliente ( delgado ) ubicado en otro lugar de la red. ^{[ 1 ]} En el lado del servidor, VirtualGL consta de una biblioteca que maneja la redirección y un programa contenedor que indica a las aplicaciones que utilicen esta biblioteca. Los clientes pueden conectarse al servidor mediante una conexión X11 remota o mediante un proxy X11, como un servidor Virtual Network Computing (VNC). En el caso de una conexión X11, también se necesita algún software VirtualGL del lado del cliente para recibir la salida gráfica renderizada por separado del flujo X11. En el caso de una conexión VNC, no se necesita ningún software específico del lado del cliente aparte del propio cliente VNC.

El rendimiento de las aplicaciones OpenGL puede mejorarse considerablemente renderizando los gráficos en aceleradores de hardware dedicados, que suelen estar presentes en las GPU . Las GPU se han vuelto tan comunes que las aplicaciones dependen de ellas para obtener un rendimiento aceptable. Sin embargo, VNC y otros entornos de cliente ligero para Unix y Linux no tienen acceso a dicho hardware en el servidor. Por lo tanto, o bien no admiten aplicaciones OpenGL , o bien recurren a métodos más lentos, como el renderizado en el cliente o mediante software en el servidor.

La visualización remota de aplicaciones 3D con aceleración de hardware tradicionalmente ha requerido el uso de la "renderización indirecta". Esta utiliza la extensión GLX del Sistema de Ventanas X ("X11" o "X") para encapsular los comandos OpenGL dentro del flujo del protocolo X11 y enviarlos desde una aplicación a una pantalla X. Tradicionalmente, la aplicación se ejecuta en un servidor de aplicaciones remoto y la pantalla X se ejecuta en el escritorio del usuario. En este caso, todos los comandos OpenGL son ejecutados por el equipo del usuario, por lo que este debe contar con un acelerador gráfico 3D rápido. Esto limita el tipo de equipo que puede mostrar remotamente una aplicación 3D mediante este método.

La renderización indirecta puede funcionar bien si la red es suficientemente rápida ( por ejemplo, Gigabit Ethernet ), si la aplicación no modifica dinámicamente la geometría del objeto que se está renderizando, si utiliza listas de visualización y si no emplea una gran cantidad de mapeo de texturas . Sin embargo, muchas aplicaciones OpenGL no cumplen estos criterios. Para complicar aún más las cosas, algunas extensiones de OpenGL no funcionan en un entorno de renderización indirecta. Algunas de estas extensiones requieren acceso directo al hardware gráfico 3D y, por lo tanto, nunca podrán funcionar de forma indirecta. En otros casos, la pantalla X del usuario puede no ofrecer compatibilidad explícita con una extensión OpenGL necesaria, o la extensión puede depender de una configuración de hardware específica que no está presente en el equipo del usuario.

Realizar el renderizado OpenGL en el servidor de la aplicación evita los problemas que introduce el renderizado indirecto, ya que la aplicación ahora tiene una ruta rápida y directa al hardware de renderizado 3D. Si el renderizado 3D se realiza en el servidor de la aplicación, entonces solo es necesario enviar las imágenes 2D resultantes al cliente. Las imágenes se pueden entregar a la misma velocidad de fotogramas independientemente del tamaño de los datos 3D utilizados para generarlas, por lo que realizar el renderizado 3D en el servidor de la aplicación convierte efectivamente el problema de rendimiento 3D en un problema de rendimiento 2D. El problema entonces radica en cómo transmitir datos de imagen de 1 a 2 megapíxeles a través de una red a velocidades de fotogramas interactivas, pero las tecnologías comerciales ( HDTV , por ejemplo) ya abordan este problema.

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 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 glXSwapBuffers() or glFinish()) 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.

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 codecs to be able to handle this workload with interactive frame rates.

VirtualGL works around this problem in two ways:

1. TurboVNC
2. The VGL Transport

VGL Transport

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

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.^[6]

La versión 2.1 del software Scalable Visualization Array de HP incluye componentes que se integran con VirtualGL y TurboVNC, lo que permite programar trabajos 3D y visualizarlos de forma remota desde un clúster de visualización. ^{[ 7 ]}

La versión 3.0.0 de ThinLinc está diseñada para funcionar conjuntamente con VirtualGL. ^{[ 8 ]}

La versión 2010 de EnginFrame Views admite VirtualGL como una de las opciones de protocolo remoto. ^{[ 9 ]}

Los productos Exceed onDemand y Exceed Freedom de OpenText utilizan código de VirtualGL para implementar la renderización del lado del servidor. ^{[ 10 ]}

• Xgl
• AIGLX

• Official website
• VirtualGL on SourceForge
• VirtualGL on GitHub
• Official TurboVNC website
• TurboVNC on SourceForge
• TurboVNC on GitHub