Excepto OpenGL, nunca usé esas bibliotecas, pero voy a tratar de adivinar, leyendo páginas de Wikipedia, como lo hiciste.
Pareces tener razón sobre Mesa. Aquí está la información adicional que tenemos:
"El sistema X window es un sistema de software de computadora y un protocolo de red que proporciona una GUI básica para las computadoras en red. Crea una capa de abstracción de hardware".
"GLX permite que los programas que deseen usar OpenGL lo hagan dentro de una ventana proporcionada por el sistema X Window.
GLX consta de tres partes:
- Una API que proporciona funciones OpenGL.
- Una extensión del protocolo X, que permite al cliente enviar 3D comandos de representación: una extensión del servidor X que recibe los comandos de representación del cliente y los pasa a la biblioteca OpenGL instalada.
Si el cliente y el servidor se ejecutan en la misma computadora y hay una tarjeta gráfica 3D acelerada disponible, los dos componentes anteriores pueden ser desviado por DRI. El programa cliente puede acceder directamente al hardware de gráficos ".
"La Infraestructura de renderizado directo (DRI) es una interfaz utilizada en el sistema X Window para permitir que las aplicaciones del usuario accedan al hardware de video sin requerir que los datos pasen a través del servidor X".
"Open Inventor es una API de gráficos 3D C ++ diseñada para proporcionar una capa más alta de programación para OpenGL"
Para simplificar las cosas, imaginemos un flujo simplificado de datos (y comandos) que ocurre en las entradas y salidas de cada una de esas API. Al principio tenemos su programa de aplicación (código compilado), que ejecuta desde su computadora. Al final tenemos imágenes que se muestran en su pantalla.
Hay varios casos que
limitaré a las respuestas a estas preguntas: -¿Tiene su computadora una tarjeta gráfica (GPU), o solo una CPU, para procesar funciones gráficas?
-es tu aplicación incrustada en una ventana del sistema x-window?
-si usa el sistema x window, ¿se está ejecutando el "servidor x" en su computadora o en otra computadora de la red?
Asumiré que tiene los controladores para su GPU si tiene uno, y que tiene Mesa para la representación del software).
Primer escenario: ejecuta una aplicación gráfica escrita con OpenInventor, sin usar el sistema X Window, y no tiene una tarjeta gráfica. El flujo del programa sería bastante similar a:
Your application
↓ (uses functions of)
OpenInventor
↓ (calls functions declared by)
OpenGL
↓ (redirects function calls to implementation defined by)
Mesa
↓ (implemented OpenGL functions to be run on the CPU)
[Probably] Operating System rendering API
↓
3D Images on your screen
Lo que sucede aquí se llama "representación de software": el comando de gráficos no es manejado por ningún hardware gráfico, sino por su CPU habitual, el procesador que generalmente ejecuta software.
Segundo escenario: ahora imagine que con las mismas condiciones que antes, tiene una tarjeta gráfica. El flujo se vería más así:
Your application
↓ (uses functions of)
OpenInventor
↓ (calls functions declared by)
OpenGL
↓ (redirects function calls to implementation defined by)
Proprietary Drivers
↓ (converts OpenGL commands to GPU commands)
Graphic Card
↓
3D Images on your screen
Lo que sucede ahora se llama "aceleración de hardware", generalmente más rápido que el primer escenario.
Tercer escenario: ahora vamos a presentar el flujo del sistema X Window, o al menos cómo creo que es, basado en las pocas líneas de Wikipedia que leí.
Olvidemos el hardware gráfico y la API por un tiempo. El flujo debería verse así:
Your application (X Window System sees it as an "X Client")
↓ (sends requests defined by the X Window System Core Protocol)
X Server
↓ (convert your request to graphic commands)
[Probably] Operating System rendering API
↓
Windows or 2D images on your screen
Tenga en cuenta que cuando usa el sistema X Window, su pantalla y la computadora desde la cual ejecuta su aplicación pueden no estar conectadas "directamente", pero podrían conectarse a través de una red.
Cuarto escenario: suponga que desea agregar representaciones gráficas 3D sofisticadas a su aplicación X Client del ejemplo anterior. Me parece que el sistema X Window no es capaz originalmente de hacer esto, o al menos necesitaría un código muy complicado para realizar el equivalente de una función API OpenGL.
Afortunadamente, puede usar GLX para agregar soporte para los comandos de OpenGL al sistema. Ahora tienes :
Your application
↓ (sends graphic requests defined by the "GLX extension to the X Protocol")
X Server with the GLX extension
↓ (convert your request to OpenGL commands)
OpenGL
↓ (redirects function calls to implementation defined by)
...
Ahora puede volver a conectar esa última flecha a la que está después de "OpenGL" en el primer escenario: ¡puede obtener imágenes en 3D en su pantalla!
Finalmente, sobre lo que creo que entiendo del DRI:
parece permitir que Mesa tenga acceso a la GPU, por lo que eso modificaría el flujo de nuestro primer escenario en:
...
↓
Mesa
↓ (forwards OpenGL commands)
DRI
↓ (converts OpenGL commands to GPU commands)
Graphic Card
↓
3D Images on your screen
Y también parece causar un cortocircuito en el flujo cuando se usa GLX, dada la condición de que su servidor y cliente estén en la misma computadora y que tenga una GPU. En ese caso, la gráfica de nuestro cuarto escenario simplemente se convertiría en:
Your application
↓ (sends graphic requests defined by the "GLX extension to the X Protocol")
DRI
↓ ("catches" OpenGL commands and converts them to GPU commands)
Graphic Card
↓
3D Images on your screen
Eso es !
Ahora tenga en cuenta que no soy un experto en entornos Unix, por lo que mi mejor consejo es estudiar la documentación de cada una de esas API para saber con precisión qué pueden hacer.
La combinación de la tabla anterior en una sola puede hacer que las cosas sean más fáciles de entender. ¡Dejo esto como ejercicio para ti!
OpenGL es independiente de la plataforma; eso significa que la API de OpenGL es independiente de la plataforma.
Los estados y las memorias intermedias de OpenGL se recopilan mediante un objeto abstracto, comúnmente denominado contexto.
La plataforma de alojamiento es responsable de proporcionar algunas API para crear el contexto OpenGL para la plataforma subyacente. En Windows existen las rutinas wgl * (Windows para GL), en Unix hay rutinas glX * (GL para X).
De hecho, GLX no es más que una API que permite que la aplicación cree contexto OpenGL, para usar la API OpenGL.
Las operaciones comunes de WGL / GLX son la creación de una ventana, la creación de un búfer fuera de la pantalla, actualizar el contexto de OpenGL en un hilo, intercambiar búferes de dibujo ...
DRI, en cambio, es una capa del núcleo que permite la comunicación directa con la tarjeta gráfica, evitando el XServer, y de hecho acelerando la aplicación usando rutinas OpenGL.
fuente
http://www.bitwiz.org.uk/s/how-dri-and-drm-work.html
La Infraestructura de renderizado directo, también conocida como DRI, es un marco para permitir el acceso directo al hardware de gráficos bajo el sistema X Window de manera segura y eficiente. Incluye cambios en el servidor X, en varias bibliotecas de clientes y en el núcleo (DRM, Direct Rendering Manager). El uso más importante para el DRI es crear implementaciones rápidas de OpenGL que proporcionen aceleración de hardware para Mesa. Se han escrito varios controladores acelerados en 3D según la especificación DRI, incluidos los controladores para conjuntos de chips producidos por 3DFX, AMD (anteriormente ATI), Intel y Matrox.
fuente
En pocas palabras, OpenGL es el tipo y la especificación de la biblioteca de gráficos. Mesa es una implicación básica. DRI es un sistema de interfaz de hardware.
Mesa básicamente se refiere a todo el marco. Sin embargo, supongo que está hablando del controlador de hardware de Mesa.
DRI es básicamente la interfaz del kernel para manejar el hardware. Técnicamente podría usarse para otras cosas, pero fue hecho para Mesa y se usa principalmente para Mesa.
GLX es como todas las interfaces con X !!
Para comprender qué es cada parte, debe saber cómo encaja.
Un programa está diseñado para interactuar con cualquier biblioteca openGL.
GLX es un medio para interactuar OpenGL con o a través de X11. Dependiendo de si tiene una interfaz "Directa" o una interfaz "Indirecta", depende de si su programa se preocupará por esto.
libGL más o menos es la interfaz para estos. Generalmente lo proporciona Mesa si está utilizando un controlador Mesa.
En una configuración indirecta va de la siguiente manera: Marco de aplicación (es decir, aplicación escrita, motor o API de abstracción) | LibGL | Mesa Driver | DRI | Hardware
En esta configuración, GLX solo se usa en el lateral para manejar la interfaz entre el uso de GL de su programa y otros programas. Aparte de las llamadas específicas de GLX que se utilizan para hacer cosas que requieren comunicación, la pila X11 y sus programas de soporte (como los administradores de ventanas) GLX está prácticamente intacto. en este arreglo
Además, el paso de comandos y la memoria compartida se pueden utilizar para optimizar aún más las capas en este sistema. Todo esto reduce las latencias y mejora la velocidad para acceder al hardware. Esto es lo que generalmente quieres.
Para un indirecto es su marco de aplicación | LibGL (lado del usuario) | LibGLX | LibGL (lado X11) | Mesa Hardware Driver | DRI | Hardware
La ventaja de esto es que no necesita un búfer de memoria compartida directa con el hardware para usar esta configuración. (Permitiendo clientes de red, así como más robustez y una configuración más segura).
Esta configuración puede funcionar en varias máquinas virtuales que comparten una sola tarjeta de video o incluso acceder a través de una red debido a esto. Algunas formas de memoria compartida o memoria virtual "clonada" compartida pueden usarse debido a las extensiones más nuevas, pero no es el acceso directo a la memoria de video que se encuentra en el modo de representación directa.
La desventaja es que el uso de tuberías o enchufes de red para interactuar con X11 puede ser lento, al menos introduciendo latencias en programas bien optimizados y, en el peor de los casos, disminuyendo drásticamente las velocidades de fotogramas en los mal optimizados.
Este es el tipo de configuración que es mejor para clientes en red, configuraciones que requieren una seguridad más sólida y configuraciones en las que múltiples sistemas operativos necesitan compartir hardware al ejecutar a través de la misma pila GL. Está lejos de ser óptimo, pero le brinda cierto grado de aceleración de hardware.
fuente