VirtualGL 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 del acelerador 3D en un servidor dedicado y envía el resultado renderizado a un cliente ( ligero ) ubicado en otra parte de la red. [1] En el lado del servidor, VirtualGL consiste en una biblioteca que maneja la redirección y un programa contenedor que indica a las aplicaciones que usen esta biblioteca. Los clientes pueden conectarse al servidor usando una conexión X11 remota o usando un proxy X11 como un VNCservidor. En el 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 el caso de una conexión VNC, no se necesita ningún software específico del lado del cliente que no sea el propio cliente VNC.
Lanzamiento estable | 2.6.3 / 25 de octubre de 2019 |
---|---|
Escrito en | C , C ++ , Unix Shell |
Licencia | Licencia pública general GNU (GPL), licencia de biblioteca wxWindows |
Sitio web | www |
Problema
El rendimiento de las aplicaciones OpenGL se puede mejorar enormemente procesando 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 clientes ligeros para Unix y Linux no tienen acceso a dicho hardware en el lado del servidor. Por lo tanto, no son compatibles con las aplicaciones OpenGL o recurren a métodos más lentos, como la renderización en el cliente o en el software del 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 de OpenGL son ejecutados por la máquina de escritorio del usuario, por lo que la 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.
El renderizado indirecto 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 usa listas de visualización y si la aplicación no usa un gran trato de mapeo de texturas . Sin embargo, muchas aplicaciones OpenGL no cumplen con estos criterios. Para complicar aún más las cosas, algunas extensiones de OpenGL no funcionan en un entorno de renderizado indirecto. Algunas de estas extensiones requieren la capacidad de acceder directamente al hardware de gráficos 3D y, por lo tanto, nunca se pueden hacer que funcionen indirectamente. En otros casos, es posible que la pantalla X del usuario no brinde 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 ejecución de renderizado OpenGL en el servidor de aplicaciones evita los problemas introducidos por el renderizado indirecto, ya que la aplicación ahora tiene una ruta rápida y directa al hardware de renderizado 3D. Si la representación 3D se produce en el servidor de aplicaciones, solo se deben enviar al cliente las imágenes 2D resultantes. Las imágenes se pueden entregar a la misma velocidad de fotogramas independientemente del tamaño de los datos 3D que se usaron para generarlas, por lo que realizar una representación 3D en el servidor de aplicaciones convierte efectivamente el problema de rendimiento 3D en un problema de rendimiento 2D. El problema entonces es cómo transmitir 1-2 megapíxeles de datos de imagen a través de una red a velocidades de cuadro interactivas, pero las tecnologías básicas ( HDTV , por nombrar una) ya abordan este problema.
La solución de VirtualGL
VirtualGL utiliza "bifurcación GLX" para realizar el renderizado OpenGL en el servidor de aplicaciones. Las aplicaciones Unix y Linux OpenGL normalmente envían tanto comandos GLX como comandos X11 ordinarios a la misma pantalla X. Los comandos GLX se utilizan para vincular contextos de renderizado OpenGL a una ventana X en particular, obtener una lista de formatos de píxeles que admite la pantalla X, etc. VirtualGL aprovecha una función en Unix y Linux que permite "precargar" una biblioteca en una aplicación, interceptando de forma eficaz (también conocido como "interposición") determinadas llamadas a funciones que la aplicación normalmente haría a las bibliotecas compartidas con las que está vinculada. Una vez que VirtualGL está precargado en una aplicación Unix o Linux OpenGL, intercepta las llamadas de función GLX desde la aplicación y las reescribe de modo que los comandos GLX correspondientes se envían a la pantalla X del servidor de aplicaciones (el "3D X Server"), que presumiblemente tiene un acelerador de hardware 3D adjunto. Por lo tanto, VirtualGL evita que los comandos GLX se envíen a través de la red a la pantalla X del usuario oa una pantalla X virtual ("proxy X"), como VNC, que no es compatible con GLX. En el proceso de reescritura de las llamadas GLX, VirtualGL también redirige la representación de OpenGL a búferes de píxeles fuera de la pantalla ("Pbuffers"). Mientras tanto, el resto de las llamadas a funciones desde la aplicación, incluidos los comandos X11 ordinarios utilizados para dibujar el usuario de la aplicación interfaz, 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, hace coincidir los atributos visuales entre la pantalla X de destino (el "Servidor X 2D") y el Servidor X 3D, y realiza una variedad de otras funciones hash para asegurar que la redirección GLX es perfecto. Pero esencialmente, una vez que se establece el contexto OpenGL en la pantalla X del servidor de aplicaciones, VirtualGL se quita del camino y permite que todos los comandos OpenGL subsiguientes pasen sin obstáculos al hardware 3D del servidor de aplicaciones. Por lo tanto, la aplicación puede usar automáticamente cualquier característica y extensión de OpenGL proporcionada por el hardware y los controladores del servidor de la aplicación.
Además de ordenar los comandos GLX y administrar Pbuffers, VirtualGL también lee los píxeles renderizados en el momento apropiado (generalmente monitoreando glXSwapBuffers()
o glFinish()
) y luego dibuja esos píxeles en la ventana X de la aplicación usando comandos de dibujo de imágenes X estándar. Dado que VirtualGL está redirigiendo los comandos GLX lejos del 2D X Server, se puede usar para agregar soporte 3D acelerado a los proxies X (como VNC), así como para evitar que ocurra la representación OpenGL indirecta cuando se usa 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 solo servidor de aplicaciones y que varios clientes compartan cada sesión. Sin embargo, VNC y sus similares están ajustados para manejar aplicaciones 2D con grandes áreas de color sólido, pocos colores y pocas diferencias entre cuadros. Las aplicaciones 3D, por otro lado, generan imágenes con patrones de color complejos y de grano fino y mucha menos correlación entre los fotogramas posteriores. 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 estándar generalmente carece de códecs de imagen lo suficientemente rápidos para poder manejar esta carga de trabajo con un marco interactivo tarifas.
VirtualGL soluciona este problema de dos formas:
- TurboVNC
- El transporte VGL
TurboVNC y TigerVNC
TurboVNC y TigerVNC son ramificaciones de TightVNC que aceleran la codificación Tight y JPEG, en parte mediante el uso de libjpeg-turbo, una versión de libjpeg acelerada por SIMD . 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 / segundo con una calidad de imagen sin pérdida de percepción. TurboVNC incluye optimizaciones adicionales que le permiten mostrar de 10 a 12 megapíxeles / segundo en un enlace de banda ancha de 5 megabits, con una calidad de imagen notablemente inferior pero utilizable. TurboVNC también amplía TightVNC para incluir almacenamiento en búfer doble del lado del cliente y otras funciones destinadas a aplicaciones 3D, como la capacidad de enviar una copia sin pérdidas de la imagen de la pantalla durante períodos de inactividad. [2] El Centro de Computación Avanzada de Texas en la Universidad de Texas en Austin utiliza TurboVNC y VirtualGL para permitir a los usuarios de TeraGrid acceder 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 proporciona el mismo rendimiento que TurboVNC pero se desempeña mejor en otros aspectos. [4]
Transporte VGL
Cuando se utiliza 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 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 apropiada. Mientras tanto, los elementos que no son OpenGL de la pantalla de la aplicación se envían a través de la red utilizando el protocolo estándar X11 remoto y se procesan en la máquina cliente.
Este enfoque requiere que una pantalla X esté presente en la máquina cliente, y la dependencia del protocolo X11 remoto para realizar renderizado 2D significa que muchas aplicaciones funcionarán mal cuando se usa el transporte VGL en redes de alta latencia. Además, VGL Transport 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 extraerlas. Pero el uso de VGL Transport proporciona una experiencia de aplicación completamente perfecta, en la que cada ventana de aplicación corresponde a una única ventana de escritorio. El transporte VGL también reduce la carga de la CPU del servidor , ya que el renderizado 2D se realiza en el cliente, y el transporte VGL permite utilizar funciones avanzadas de OpenGL, como estéreo con búfer cuádruple .
Los desarrolladores de VirtualGL imaginan que los usuarios principales del transporte VGL serán usuarios de portátiles con una conexión inalámbrica 802.11g o una conexión Ethernet rápida al servidor de aplicaciones.
Productos comerciales que utilizan VirtualGL
VirtualGL y TurboVNC eran componentes centrales del producto Sun Visualization System de Sun Microsystems , que se suspendió 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 cerrado. paquete de origen que integró VirtualGL con Sun Grid Engine , proporcionando administració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 cobró por el apoyo.
v4.xx de NoMachine es compatible con VirtualGL para permitir a los usuarios ejecutar aplicaciones 3D en sesiones de escritorio de NoMachine. [5]
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 mostrarlos de forma remota desde un clúster de visualización. [6]
La v3.0.0 de ThinLinc está diseñada para funcionar junto con VirtualGL. [7]
v2010 de EnginFrame Views admite VirtualGL como una de las opciones de protocolo remoto. [8]
Los productos Exceed onDemand y Exceed Freedom de OpenText usan código de VirtualGL para implementar la representación del lado del servidor. [9]
Ver también
- Xgl
- AIGLX
Referencias
Notas al pie
- ^ "Una breve introducción a VirtualGL" . VirtualGL.org . Consultado el 20 de febrero de 2016 .
- ^ "Una breve introducción a TurboVNC" . TurboVNC.org . Consultado el 20 de febrero de 2016 .
- ^ "Guía del usuario de Stampede" . Centro de Computación Avanzada de Texas (TACC) . Consultado el 29 de febrero de 2016 .
- ^ "VirtualGL" . ArchLinux.org . Consultado el 25 de junio de 2021 .
- ^ "Habilitación de la compatibilidad con VirtualGL en NoMachine 4 o posterior" . NoMachine.com . Consultado el 20 de febrero de 2016 .
- ^ "Computación de alto rendimiento (HPC)" . Hp.com. Archivado desde el original el 9 de agosto de 2014 . Consultado el 17 de febrero de 2015 .
- ^ "Guía del administrador de ThinLinc para ThinLinc 4.5.0" . ThinLinc.com . Consultado el 20 de febrero de 2016 .
- ^ "Visualización remota" . Nice-software.com . Consultado el 17 de febrero de 2015 .
- ^ "Guía del usuario de Open Text Exceed, versión 14" (PDF) . Kb.berkeley.edu. 12 de junio de 2012.
Referencias generales
- "Fondo de VirtualGL" . VirtualGL.org . Consultado el 20 de febrero de 2016 .
- "Guía del usuario de VirtualGL 2.5" . VirtualGL.org . Consultado el 20 de febrero de 2016 .
- "Guía del usuario de TurboVNC 2.0.1" . TurboVNC.org . Consultado el 20 de febrero de 2016 .
enlaces externos
- Sitio web oficial de VirtualGL
- VirtualGL en SourceForge.net
- VirtualGL en GitHub
- Sitio web oficial de TurboVNC
- TurboVNC en SourceForge.net
- TurboVNC en GitHub