Edición de «VirtualGL»

{{Ficha de software
| nombre = VirtualGL
| última_versión        = 2.3
| fecha_última_versión  = {{fecha de lanzamiento|13|12|2011}}
| lenguaje_programación = [[C (lenguaje de programación)|C]], [[C++]], Shell de [[Unix]]
| estado     = en desarrollo
| género     = software de [[administración remota]]
| licencia   = [[GNU General Public License]] (GPL), wxWindows Library Licence
| sitio_web  = http://www.virtualgl.org/
| idiomas    = [[Idioma inglés|inglés]]
| español    = No
}}

'''VirtualGL''' es un programa de [[open source|código abierto]] que redirige los comandos de procesamiento de aplicaciones [[3D]] [[OpenGL]] de [[Unix]] y [[Linux]] para hardware [[Unidad de procesamiento gráfico|acelerador 3D]] en un [[servidor dedicado]] y muestra el resultado representado interactivamente a un [[cliente liviano]] localizado en cualquier lugar de la red.

== El problema ==
Normalmente, [[Virtual Network Computing|VNC]] y otros entornos de cliente ligero para Unix y Linux o no soportan las aplicaciones OpenGL para nada o fuerzan a las aplicaciones OpenGL a [[Renderización|renderizarse]] sin el beneficio de [[aceleración por hardware]] OpenGL. Mostrar de forma remota aplicaciones 3D con aceleración de hardware tradicionalmente ha requerido el uso de "representación indirecta". La representación indirecta utiliza la extensión [[GLX]] de la [[X Window System|Sistema x Window ("X11" o "X")]] para encapsular los comandos OpenGL dentro de la [[Protocolos y arquitectura de X Window System|fuente de protocolo X11]] y enviarlos desde una aplicación a una pantalla de X. Tradicionalmente, la aplicación se ejecuta en un servidor de aplicaciones de forma remota localizada y la visualización de x se ejecuta en el escritorio del usuario. En este escenario, todos los comandos de OpenGL son ejecutados por el equipo 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 remotamente puede mostrar una aplicación 3D utilizando este método.

La renderización indirecta puede demostrarse suficientemente funcional si la red es lo suficientemente rápida (si usa [[Gigabit Ethernet]], por ejemplo), si la aplicación no modifica dinámicamente la geometría del objeto que se representa, si la aplicación utiliza [[lista de despliegue|listas de pantalla]], y si la aplicación utiliza una gran cantidad de [[Textura (gráficos por computadora)|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 representación indirecta. Algunas de estas extensiones requieren la capacidad de acceder directamente en el hardware de gráficos 3D y por lo tanto nunca es posible trabajar indirectamente. En otros casos, la pantalla X del usuario no puede proporcionar apoyo explícito para una extensión de OpenGL necesaria o la extensión puede depender de una configuración de [[hardware]] específico que no está presente en el equipo de escritorio del usuario.

Renderizando (procesando) OpenGL en el servidor de aplicaciones se eluden los problemas introducidos por la representación indirecta, dado que la aplicación ahora dispone de un camino de acceso rápido y directo al hardware de procesamiento de 3D. Si la representación 3D se produce en el servidor de aplicaciones, solo las imágenes [[2D]] resultantes deben enviarse al escritorio del usuario. Las imágenes pueden entregarse a la misma velocidad de fotograma independientemente del tamaño de los datos 3D que fueron utilizados para generarlos, así que realizar procesamiento (renderizado) de 3D en el servidor de aplicaciones efectivamente convierte el problema de rendimiento 3D en un problema de rendimiento en 2D. El problema se convierte en cómo tratar un flujo de 1-2 [[megapíxel]]es de datos de imagen en una red a velocidades de [[Frame Relay|fotograma]] interactivas, pero las tecnologías de productos básicos ([[HDTV]], por nombrar uno) ya abordan este problema.

== La solución OpenGL ==

Biblioteca (informática)
VirtualGL utiliza "GLX duplicidad" para realizar el procesamiento OpenGL en el servidor de aplicaciones. Normalmente, las aplicaciones UNIX y Linux OpenGL envían comandos GLX y ordinarias X 11 comandos al mismo x mostrar. Se utilizan los comandos GLX a contextos de procesamiento OpenGL se unen a un particular x ventana, obtener una lista de formatos de píxel que el x mostrar apoyos, etc.. VirtualGL aprovecha una característica en Unix y Linux que permite "cargar" una biblioteca en una aplicación, efectivamente interceptar (AKA "interposición") cierta función llama a que la aplicación podría realizar normalmente [[biblioteca (informática) # Dynamic_linking|shared bibliotecas]] con la que está vinculado. Una vez que VirtualGL está precargado en una aplicación Unix o Linux OpenGL, intercepta las llamadas a funciones de la aplicación GLX y les reescribe tal que la GLX correspondiente comandos se envían al servidor de aplicaciones x display, que presumiblemente tiene un acelerador de hardware 3D conectado. Así, VirtualGL impide comandos GLX que se envían por la red x mostrar al usuario o a un virtual x pantalla ("X proxy"), como el VNC, que no admite GLX. En el proceso de reescritura de las llamadas GLX, VirtualGL también redirige el procesamiento OpenGL en búferes de píxeles fuera de la pantalla ("Pbuffers.") Mientras tanto, el resto de las llamadas de función de la aplicación, incluido el ordinario X 11 comandos utilizados para dibujar la interfaz de usuario de la aplicación, pueden pasar a través de VirtualGL sin modificaciones.

Internamente, el motor intermedio (interposer) del VirtualGL también mantiene un mapa de ventanas a Pbuffers, que relaciona atributos visuales entre la pantalla de destino X y la pantalla X en la que se producirá la representación 3D y realiza una serie de otras funciones de hash (hashing) para asegurar que la redirección GLX es transparente. Pero, esencialmente, una vez establecido el contexto de OpenGL en la pantalla del servidor de aplicaciones X, VirtualGL sale del camino y se permite a todos los comandos posteriores OpenGL pasar sin trabas al hardware 3D del servidor de aplicaciones. Así, la aplicación puede utilizar automáticamente las funciones OpenGL y extensiones proporcionadas por el hardware y controladores del servidor de aplicaciones.

Aparte del ordenamiento de comandos GLX y administración de Pbuffers, VirtualGL también lee hacia atrás los píxeles renderizados en el momento oportuno (generalmente por supervisión <code>glXSwapBuffers()</code> or <code>glFinish()</code>) y, a continuación, dibuja los píxeles en la ventana X de la aplicación utilizando x comandos de dibujo de imagen estándar X. Como VirtualGL redirige los comandos GLX fuera de la pantalla de destino X, puede utilizarse para agregar soporte 3D acelerado a servidores proxy X (como VNC) así como para prevenir el renderizado indirecto de OpenGL al usar una pantalla remota X.

[[Image:X11transport.png|thumb|right|400px|Cuando se usa el X11 Image Transport (anteriormente "modo de Proxy"), los renderizados 3D y 2D se producen en el servidor de aplicaciones. VirtualGL redirige los comandos 3D desde la aplicación al hardware acelerador 3D, lee hacia atrás las imágenes procesadas y les dibuja como una serie de mapas de bits sin comprimir en el proxy X (VNC o sistema similar). Mientras, los comandos de dibujo 2D (comandos X11) de la aplicación se envían al servidor proxy X directamente. El proxy X es el único responsable de la compresión de las imágenes y su envío a los clientes remotos.]]

Usar VirtualGL en concierto con VNC u otro proxy X permite que varios usuarios simultáneamente ejecuten aplicaciones 3D en un servidor de aplicación único y varios clientes para compartir cada sesión. Sin embargo, VNC y su tropa están ajustados para manejar aplicaciones 2D con grandes áreas de color sólido, pocos colores y pocas diferencias inter-frame. Las aplicaciones 3D, por otra parte, generan imágenes con patrones de color complejo de grano fino, y mucha menos correlación entre los fotogramas posteriores. La carga de trabajo generado dibujando imágenes renderizadas desde una aplicación de OpenGL en una ventana X es esencialmente la misma carga de trabajo de un reproductor de vídeo, y un software de cliente ligero disponible normalmente carece de [[códec]]s de imagen suficientemente rápidos para poder manejar esta carga de trabajo con velocidades de fotograma interactivas.

VirtualGL trabaja en todo este problema de dos maneras:
# Mediante TurboVNC
# Mediante transporte de imagen CFR

=== TurboVNC ===
'''TurboVNC''' es una rama (''offshoot'') de [[TightVNC]] que acelera las rutas de codificación Tight y JPEG de éste, aprovechando las ventajas de [[libjpeg]]-turbo, una versión acelerada por SIMD de [[libjpeg]]. En [[Fast Ethernet|redes de 100 megabits Ethernet]], TurboVNC es capaz de mostrar imágenes de pantalla completa (1280 x 1024 píxeles) con calidad de imagen sin pérdidas perceptibles en más de 20 fotogramas por segundo. TurboVNC incluye optimizaciones adicionales que permiten mostrar las imágenes de pantalla completa en 7-10 fotogramas por segundo en banda ancha, con calidad de imagen notablemente menor pero utilizable. TurboVNC extiende también TightVNC para incluir [[Buffer múltiple|doble búfer]] en el lado del cliente y otras características dirigidas a  aplicaciones 3D, así como plena compatibilidad con [[Solaris (sistema operativo)|plataformas Solaris]]. TurboVNC y VirtualGL son utilizados por el [[TACC|Centro Tejano de Cómputo Académico (TACC)]] de la [[Universidad de Texas en Austin]] para que los usuarios de [[TeraGrid]] puedan acceder remotamente a las capacidades de procesamiento 3D del clúster de visualización [https://web.archive.org/web/20110505165620/http://services.tacc.utexas.edu/index.php/longhorn-user-guide Longhorn].

=== Transporte de imagen VGL (anteriormente "modo directo") ===
[[Image:VGLtransport.png|thumb|right|400px|Cuando se utiliza el transporte de imagen de CFR (anteriormente "modo directo"), la representación 3D se produce en el servidor de aplicaciones, pero la representación 2D se produce en el equipo cliente. VirtualGL comprime las imágenes renderizadas desde la aplicación 3D y los envía como un flujo de vídeo para el cliente, que descomprime y muestra la secuencia de vídeo en tiempo real.]]
Cuando se utiliza el transporte de imagen '''VGL Image Transport''', VirtualGL comprime imágenes 3D renderizadas en proceso utilizando el mismo códec [[JPEG]] optimizado que utiliza TurboVNC. VirtualGL, a continuación, envía las imágenes comprimidas sobre un [[socket]] [[Transmission Control Protocol|TCP]] dedicado a una aplicación cliente de VirtualGL que se ejecuta en la máquina cliente. El cliente VirtualGL es responsable de la descompresión de las imágenes y de dibujar los píxeles en la ventana X apropiada. Mientras tanto, los elementos no OpenGL de pantalla de la aplicación son enviados a través de la red mediante el [[X Display Manager|protocolo de control estándar remoto X11]] y renderizados en el equipo cliente.

Este enfoque requiere que una pantalla X esté presente en el equipo cliente y que se confíe en el protocolo remoto X11 para llevar a cabo representación 2D, lo que significa que muchas aplicaciones se desempeñarán pobremente al utilizar el transporte de imagen VGL Image Transport en redes de alta latencia. Además, el transporte de imagen VGL no permite inherentemente la colaboración (varios clientes por sesión), ya que las imágenes son 'empujadas' a los equipos de los usuarios en lugar de tirarse de ellas. Pero el uso del transporte de imagen VGL ofrece una experiencia de aplicación completamente integrada, mediante el cual cada ventana de la aplicación corresponde a una única ventana del escritorio. El transporte de imagen VGL también reduce la carga de [[CPU]] del servidor, ya que el renderizado 2D se está produciendo en el ordenador/computador cliente y el transporte de imagen VGL permite el uso de funciones avanzadas de OpenGL, como [[Sonido estereofónico|estéreo]] [[Quad buffering|cuadri-bufferado]].

Los desarrolladores de VirtualGL visualizaron que los principales usuarios del transporte de imagen VGL serían los usuarios de [[computadora portátil|portátiles]] con [[wireless|conexión inalámbrica a internet]] [[802.11|802.11g]] o una conexión Ethernet rápida al servidor de aplicaciones.

== Soluciones comerciales que usan VirtualGL ==
VirtualGL y TurboVNC fueron los componentes principales del producto [[Sun Visualization System|Sistema de visualización de Sun]] de [[Sun Microsystems]], que fue suspendido en abril de 2009. Los dos paquetes de [[código abierto]] se combinaron con un plugin de [[software privativo|código cerrado]] que permite a VirtualGL a enviar imágenes comprimidas a [[cliente liviano|clientes ligeros]] [[Sun Ray]] y otro paquete de código cerrado que integraba VirtualGL con [[Sun Grid Engine]], proporcionando administración de recursos y la programación de trabajos 3D remotos. La combinación de estos paquetes, llamada "Sun Shared Visualization" ("Visualización compartida de Sun"), estaba disponible como descarga gratuita (Sun cobraba por asistencia de apoyo).

La versión v2.1 del software [https://web.archive.org/web/20140809192316/http://h20311.www2.hp.com/HPC/cache/281455-0-0-0-121.html Scalable Visualization Array  (matriz de visualización escalable)] de [[Hewlett-Packard|HP]] también incluye componentes que se integran con VirtualGL y TurboVNC, permitiendo programar y mostrar remotamente desde un clúster de visualización trabajos en 3D.

La versión v3.0.0 de [[ThinLinc]] está diseñada para trabajar en conjunto con VirtualGL.

== Referencias ==
{{listaref}}

== Véase también ==
{{Portal|Software libre}}
* [[X Window System]]
* [[Xgl]]
* [[AIGLX]]
* [[VNC]]
* [[OpenGL]]

== Enlaces externos ==
*[http://www.virtualgl.org/ Sitio web oficial]
*{{SourceForge|virtualgl}}

{{Control de autoridades}}
[[Categoría:Sistemas libres de gestión de ventanas]]
[[Categoría:OpenGL]]
[[Categoría:Cliente liviano]]