VirtualGL ( VGL ) es un paquete de software de código abierto que redirige los comandos de renderizado 3D de las aplicaciones OpenGL de Unix y Linux al hardware acelerador 3D en un servidor dedicado y envía la salida renderizada a un cliente ( delgado ) ubicado en otra parte de la red. [1] En el lado del servidor, VirtualGL consta de una biblioteca que maneja la redirección y un programa contenedor que instruye a las aplicaciones a usar esta biblioteca. Los clientes pueden conectarse al servidor ya sea usando una conexión X11 remota o usando un proxy X11 como un servidor Virtual Network Computing (VNC). En caso de una conexión X11 también se necesita algún software VirtualGL del lado del cliente para recibir la salida de gráficos renderizados por separado de la transmisión X11. En 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 se puede mejorar en gran medida si se renderizan los gráficos en aceleradores de hardware dedicados que suelen estar presentes en una GPU . Las GPU se han vuelto tan comunes que las aplicaciones han llegado a depender de ellas para obtener un rendimiento aceptable. Pero VNC y otros entornos de cliente ligero para Unix y Linux no tienen acceso a dicho hardware en el lado del servidor. Por lo tanto, no admiten aplicaciones OpenGL en absoluto o recurren a métodos más lentos, como la renderización en el cliente o en el software en el servidor.
La visualización remota de aplicaciones 3D con aceleración de hardware ha requerido tradicionalmente el uso de "renderizado indirecto". El renderizado indirecto utiliza la extensión GLX del sistema X Window ("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 ubicado de forma remota y la pantalla X se ejecuta en el escritorio del usuario. En este escenario, todos los comandos OpenGL se ejecutan en la máquina de escritorio del usuario, por lo que esa máquina debe tener un acelerador de gráficos 3D rápido. Esto limita el tipo de máquina que puede mostrar de forma remota una aplicación 3D utilizando este método.
La renderización indirecta puede funcionar bien si la red es lo suficientemente rápida ( Gigabit Ethernet , por ejemplo), si la aplicación no modifica dinámicamente la geometría del objeto que se está renderizando, si la aplicación utiliza listas de visualización y si la aplicación no utiliza 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 OpenGL no funcionan en un entorno de renderización indirecta. Algunas de estas extensiones requieren la capacidad de acceder directamente al hardware de gráficos 3D y, por lo tanto, nunca se puede hacer que funcionen indirectamente. En otros casos, la pantalla X del usuario puede no proporcionar soporte explícito para una extensión OpenGL necesaria, o la extensión puede depender de una configuración de hardware específica que no está presente en la máquina de escritorio del usuario.
La realización de la renderización OpenGL en el servidor de aplicaciones evita los problemas introducidos por la renderización indirecta, ya que la aplicación ahora tiene una ruta rápida y directa al hardware de renderización 3D. Si la renderización 3D se produce en el servidor de aplicaciones, entonces solo las imágenes 2D resultantes deben enviarse al cliente. Las imágenes se pueden entregar a la misma velocidad de cuadros independientemente de lo grandes que sean los datos 3D que se utilizaron para generarlas, por lo que la realización de la renderización 3D en el servidor de aplicaciones convierte efectivamente el problema de rendimiento 3D en un problema de rendimiento 2D. El problema entonces se convierte en cómo transmitir 1-2 megapíxeles de datos de imagen a través de una red a velocidades de cuadros interactivas, pero las tecnologías de consumo ( HDTV , por nombrar una) ya abordan este problema.
VirtualGL utiliza la "bifurcación GLX" para realizar la renderización OpenGL en el servidor de aplicaciones. Las aplicaciones OpenGL de Unix y Linux normalmente envían comandos GLX y comandos X11 ordinarios a la misma pantalla X. Los comandos GLX se utilizan para vincular contextos de renderización OpenGL a una ventana X en particular, obtener una lista de formatos de píxeles que la pantalla X admite, etc. VirtualGL aprovecha una característica de Unix y Linux que permite "precargar" una biblioteca en una aplicación, interceptando de manera efectiva (también conocida como "interponiendo") ciertas llamadas de función que la aplicación normalmente haría a bibliotecas compartidas con las que está vinculada. Una vez que VirtualGL se precarga en una aplicación OpenGL de Unix o Linux, intercepta las llamadas de función GLX de la aplicación y las reescribe de manera que los comandos GLX correspondientes se envíen a la pantalla X del servidor de aplicaciones (el "Servidor X 3D"), que presumiblemente tiene un acelerador de hardware 3D conectado. De esta forma, VirtualGL evita 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 admita GLX. En el proceso de reescritura de las llamadas GLX, VirtualGL también redirige la representación OpenGL a búferes de píxeles fuera de la pantalla ("Pbuffers"). Mientras tanto, el resto de las llamadas a funciones de la aplicación, incluidos los comandos X11 ordinarios 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 en Pbuffers, combina atributos visuales entre la pantalla X de destino (el "Servidor X 2D") y el Servidor X 3D, y realiza una variedad de otras funciones de hash para asegurar que la redirección GLX sea perfecta. Pero esencialmente, una vez que el contexto OpenGL se establece en la pantalla X del servidor de aplicaciones, VirtualGL se hace a un lado y permite que todos los comandos OpenGL posteriores pasen sin impedimentos al hardware 3D del servidor de aplicaciones. De este modo, la aplicación puede usar automáticamente cualquier característica y extensión OpenGL que proporcionen el hardware y los controladores del servidor de aplicaciones.
Además de ordenar los comandos GLX y administrar los Pbuffers, VirtualGL también lee los píxeles renderizados en el momento adecuado (generalmente mediante la supervisión glXSwapBuffers()o glFinish()) y luego dibuja esos píxeles en la ventana X de la aplicación utilizando comandos de dibujo de imágenes X estándar. Dado que VirtualGL está redireccionando los comandos GLX fuera del servidor X 2D, se puede utilizar para agregar soporte 3D acelerado a los proxies X (como VNC) así como para evitar que se produzca una renderización indirecta de OpenGL cuando se utiliza 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 sus similares están optimizados para manejar aplicaciones 2D con grandes áreas de color sólido, pocos colores y pocas 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 subsiguientes. La carga de trabajo generada al dibujar imágenes renderizadas desde una aplicación OpenGL en una ventana X es esencialmente la misma carga de trabajo que un reproductor de video, y el software de cliente ligero comercial generalmente carece de códecs de imagen lo suficientemente rápidos como para poder manejar esta carga de trabajo con velocidades de fotogramas interactivas.
VirtualGL soluciona este problema de dos maneras:
TurboVNC y TigerVNC son derivaciones de TightVNC que aceleran la codificación Tight y JPEG, en parte mediante el uso de libjpeg-turbo, una versión acelerada por SIMD de libjpeg . Ambos proyectos proporcionan servidores VNC y aplicaciones cliente.
TurboVNC fue desarrollado por el mismo equipo que VirtualGL. En redes Ethernet de 100 megabits puede mostrar más de 50 megapíxeles por segundo con una calidad de imagen sin pérdida de percepción. TurboVNC incluye optimizaciones adicionales que le permiten mostrar entre 10 y 12 megapíxeles por segundo en un enlace de banda ancha de 5 megabits, con una calidad de imagen notablemente menor, pero utilizable. TurboVNC también amplía TightVNC para incluir doble almacenamiento en búfer del lado del cliente y otras funciones destinadas a aplicaciones 3D, como la capacidad de enviar una copia sin pérdida de la imagen de la pantalla durante períodos de inactividad. [2] TurboVNC y VirtualGL son utilizados por el Centro de Computación Avanzada de Texas en la Universidad de Texas en Austin para permitir que los usuarios de TeraGrid accedan de forma remota a las capacidades de renderizado 3D del clúster de visualización Stampede [3] .
TigerVNC es una bifurcación más reciente de TightVNC que ofrece un rendimiento similar a TurboVNC en la mayoría de los casos, pero tiene diferentes objetivos y características del proyecto. [4] [5]
Al utilizar el transporte VGL, VirtualGL comprime las imágenes 3D renderizadas en proceso utilizando el mismo códec JPEG optimizado que utiliza TurboVNC. Luego, VirtualGL envía las imágenes comprimidas a través de un socket TCP dedicado a una aplicación de cliente VirtualGL que se ejecuta en la máquina cliente. El cliente VirtualGL es responsable de descomprimir las imágenes y dibujar los píxeles en la ventana X adecuada. Mientras tanto, los elementos no OpenGL de la pantalla de la aplicación se envían a través de la red utilizando el protocolo X11 remoto estándar y se renderizan en la máquina cliente.
Este enfoque requiere que haya una pantalla X en la máquina cliente, y la dependencia del protocolo X11 remoto para realizar la renderización 2D significa que muchas aplicaciones tendrán un rendimiento deficiente al utilizar el Transporte VGL en redes de alta latencia. Además, el Transporte VGL no admite de forma inherente la colaboración (varios clientes por sesión), ya que las imágenes se envían a las máquinas de los usuarios en lugar de extraerse. Pero el uso del Transporte VGL proporciona una experiencia de aplicación completamente fluida, por la que cada ventana de la aplicación corresponde a una única ventana del escritorio. El Transporte VGL también reduce la carga de la CPU del servidor, ya que la renderización 2D se realiza en el cliente, y el Transporte VGL permite utilizar funciones avanzadas de OpenGL, como el estéreo con búfer cuádruple .
Los desarrolladores de VirtualGL prevén que los usuarios principales de VGL Transport sean usuarios de 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 básicos del producto Sun Visualization System de Sun Microsystems , que se dejó de fabricar en abril de 2009. Los dos paquetes de código abierto se combinaron con un complemento de código cerrado que permitía a VirtualGL enviar imágenes comprimidas a clientes ligeros Sun Ray y otro paquete de código cerrado que integraba VirtualGL con Sun Grid Engine , lo que proporcionaba gestión de recursos y programación para trabajos 3D remotos. La combinación de estos paquetes, denominada "Sun Shared Visualization", estaba disponible como descarga gratuita. Sun cobraba por el soporte.
La versión v4.xx de NoMachine admite VirtualGL para permitir a los usuarios ejecutar aplicaciones 3D en sesiones de escritorio 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 v3.0.0 de ThinLinc está diseñada para funcionar junto con VirtualGL. [8]
La versión v2010 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 representación del lado del servidor. [10]
.svg/1280px-Free_and_open-source_software_logo_(2009).svg.png){kind=logo}