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 utiliza la técnica de "bifurcación GLX" para realizar la renderización de OpenGL en el servidor de aplicaciones. Las aplicaciones OpenGL de Unix y Linux normalmente envían comandos GLX y comandos X11 estándar a la misma pantalla X. Los comandos GLX se utilizan para vincular contextos de renderización de OpenGL a una ventana X específica, obtener una lista de formatos de píxeles compatibles con la pantalla X, etc. VirtualGL aprovecha una función de Unix y Linux que permite "precargar" una biblioteca en una aplicación, interceptando (o "interponiendo") ciertas llamadas a funciones que la aplicación realizaría normalmente a las bibliotecas compartidas con las que está vinculada. Una vez precargado, VirtualGL intercepta las llamadas a funciones GLX de la aplicación y las modifica para que los comandos GLX correspondientes se envíen a la pantalla X del servidor de aplicaciones (el "Servidor X 3D"), que presumiblemente cuenta con un acelerador de hardware 3D. De este modo, VirtualGL impide que los comandos GLX se envíen a través de la red a la pantalla X del usuario o a una pantalla X virtual ("X proxy"), como VNC, que no sea compatible con GLX. Al reescribir las llamadas GLX, VirtualGL también redirige la renderización de OpenGL a búferes de píxeles fuera de pantalla ("Pbuffers"). Mientras tanto, el resto de las llamadas a funciones de la aplicación, incluidos los comandos X11 habituales utilizados para dibujar la interfaz de usuario de la aplicación, pueden pasar a través de VirtualGL sin modificaciones.

Internamente, el motor de interposición de VirtualGL también mantiene un mapa de ventanas a Pbuffers, compara los atributos visuales entre la pantalla X de destino (el "Servidor X 2D") y el Servidor X 3D, y realiza diversas funciones hash para asegurar una redirección GLX fluida. En esencia, una vez establecido el contexto OpenGL en la pantalla X del servidor de aplicaciones, VirtualGL deja de interferir y permite que todos los comandos OpenGL subsiguientes se transmitan sin impedimentos al hardware 3D del servidor. De este modo, la aplicación puede utilizar automáticamente las funciones y extensiones de OpenGL que proporcionan el hardware y los controladores del servidor.

Además de gestionar los comandos GLX y los Pbuffers, VirtualGL también lee los píxeles renderizados en el momento adecuado (normalmente mediante monitorización glXSwapBuffers()) glFinish()y luego los dibuja en la ventana X de la aplicación utilizando comandos estándar de dibujo de imágenes X. Dado que VirtualGL redirige los comandos GLX fuera del servidor X 2D, puede utilizarse para añadir compatibilidad 3D acelerada a proxies X (como VNC) y para evitar la renderización indirecta de OpenGL al utilizar una pantalla X remota.

El uso de VirtualGL junto con VNC u otro proxy X permite que varios usuarios ejecuten simultáneamente aplicaciones 3D en un único servidor de aplicaciones y que varios clientes compartan cada sesión. Sin embargo, VNC y similares están optimizados para manejar aplicaciones 2D con grandes áreas de color sólido, pocos colores y escasas diferencias entre fotogramas. Las aplicaciones 3D, por otro lado, generan imágenes con patrones de color complejos y de grano fino, y mucha menos correlación entre fotogramas consecutivos. La carga de trabajo generada al dibujar imágenes renderizadas desde una aplicación OpenGL en una ventana X es esencialmente la misma que la de un reproductor de vídeo, y el software cliente ligero comercial generalmente carece de códecs de imagen lo suficientemente rápidos como para manejar esta carga de trabajo con velocidades de fotogramas interactivas.

VirtualGL soluciona este problema de dos maneras:

1. TurboVNC
2. El transporte VGL

Transporte VGL

Al usar el transporte VGL, VirtualGL comprime las imágenes 3D renderizadas en el proceso utilizando el mismo códec JPEG optimizado que TurboVNC. A continuación, VirtualGL envía las imágenes comprimidas a través de un socket TCP dedicado a una aplicación cliente VirtualGL que se ejecuta en la máquina cliente. El cliente VirtualGL se encarga de descomprimir las imágenes y dibujar los píxeles en la ventana X correspondiente. Mientras tanto, los elementos que no son OpenGL de la pantalla de la aplicación se envían a través de la red mediante el protocolo remoto X11 estándar y se renderizan en la máquina cliente.

Este enfoque requiere que el cliente tenga una pantalla X, y la dependencia del protocolo remoto X11 para la renderización 2D implica que muchas aplicaciones tendrán un rendimiento deficiente al usar VGL Transport en redes de alta latencia. Además, VGL Transport no admite la colaboración (múltiples clientes por sesión), ya que las imágenes se envían a los equipos de los usuarios en lugar de descargarse. Sin embargo, el uso de VGL Transport proporciona una experiencia de aplicación totalmente fluida, donde cada ventana de aplicación corresponde a una única ventana de escritorio. VGL Transport también reduce la carga de la CPU del servidor, ya que la renderización 2D se realiza en el cliente, y permite el uso de funciones avanzadas de OpenGL, como el estéreo con búfer cuádruple .

Los desarrolladores de VirtualGL prevén que los principales usuarios de VGL Transport serán usuarios de ordenadores portátiles con una conexión inalámbrica 802.11g o una conexión Ethernet rápida al servidor de aplicaciones.

VirtualGL y TurboVNC eran componentes clave del sistema de visualización Sun de Sun Microsystems , que se descontinuó en abril de 2009. Estos dos paquetes de código abierto se combinaban con un complemento de código cerrado que permitía a VirtualGL enviar imágenes comprimidas a los clientes ligeros Sun Ray , y otro paquete de código cerrado que integraba VirtualGL con Sun Grid Engine , proporcionando gestión de recursos y programación para trabajos 3D remotos. La combinación de estos paquetes, denominada "Sun Shared Visualization", estaba disponible para su descarga gratuita. Sun cobraba por el soporte.

La versión 4.xx de NoMachine admite VirtualGL para permitir a los usuarios ejecutar aplicaciones 3D en sesiones de escritorio de NoMachine. ^{[ 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

• Sitio web oficial
• VirtualGL en SourceForge
• VirtualGL en GitHub
• Sitio web oficial de TurboVNC
• TurboVNC en SourceForge
• TurboVNC en GitHub