¿Cuál es la relación entre OpenGL, GLX, DRI y Mesa3D?

15

Estoy empezando a hacer una programación 3D de bajo nivel en Linux. Tengo mucha experiencia en el uso de la API de gráficos de nivel superior OpenInventor.

Sé que no es estrictamente necesario ser consciente de cómo encajan todas estas cosas, pero tengo curiosidad. Sé que OpenGL es solo un estándar para aplicaciones de gráficos. Mesa3D parece ser una implementación de código abierto de este estándar.

Entonces, ¿dónde encajan GLX y DRI? Buscando en Wikipedia y en todos estos sitios web, todavía tengo que encontrar una explicación de cómo va todo junto. ¿Dónde ocurre la aceleración de hardware? ¿Qué tienen que ver los controladores propietarios con esto?

    
pregunta ttb 15.09.2012 - 21:22
fuente

4 respuestas

14

Excepto OpenGL, nunca usé esas bibliotecas, pero voy a intentar adivinar, leyendo páginas de wikipedia, como hiciste.

Pareces tener razón sobre Mesa. Aquí está la información adicional que tenemos:

"El sistema de ventanas X es un sistema de software y un protocolo de red que proporciona una GUI básica para las computadoras en red. Crea una abstracción de hardware. capa. "

"GLX permite que los programas que deseen usar OpenGL lo hagan dentro de una ventana provista por X Window System.
GLX consta de tres partes:
- Una API que proporciona funciones de OpenGL.
- Una extensión del protocolo X, que permite al cliente enviar comandos de representación 3D - Una extensión del servidor X que recibe los comandos de representación del cliente y los pasa a la biblioteca de OpenGL instalada. Si el cliente y el servidor se ejecutan en la misma computadora y hay disponible una tarjeta gráfica 3D acelerada, DRI puede omitir los dos componentes anteriores. A continuación, se permite que el programa cliente acceda directamente al hardware de gráficos ".

"Infraestructura de representación directa (DRI) es una interfaz utilizada en el sistema X Window para permitir que las aplicaciones de los usuarios accedan al hardware de video sin necesidad de datos que se pasarán a través del servidor X. "

"Open Inventor es una API de gráficos 3D C ++ diseñada para proporcionar una capa superior 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 restringiré a las respuestas a estas preguntas:
¿Tiene su computadora una tarjeta gráfica (GPU) o solo una CPU para procesar funciones gráficas?
-¿Está tu aplicación incrustada en una ventana del sistema x-window?
-Si usa el sistema de ventanas x, ¿se ejecuta 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 denomina "representación de software": el comando de gráficos no se maneja con ningún hardware gráfico, sino con su CPU habitual, el procesador que generalmente ejecuta el software.

Segundo escenario: ahora imagine que con las mismas condiciones que arriba, 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 introduzcamos el flujo del sistema X Window, o al menos cómo lo creo, basado en las pocas líneas de Wikipedia que leí.
Olvidemos por un momento el hardware gráfico y la API. El flujo debe verse como:

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 al usar el sistema X Window, su pantalla y la computadora desde la que ejecuta su aplicación pueden no estar "directamente" conectadas, pero podrían estar conectadas a través de una red.

Cuarto escenario: suponga que desea agregar representaciones gráficas 3D de lujo a su aplicación X Client del ejemplo anterior. Me parece que el X Window System originalmente no puede hacer esto, o al menos necesitaría mucho código complicado para realizar el equivalente de una función de la API OpenGL.
Afortunadamente, puede usar GLX para agregar compatibilidad con los comandos 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 la ú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 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 provocar 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 todo!
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 exactamente lo que pueden hacer.
Combinar el cuadro anterior en uno solo puede hacer las cosas más fáciles de entender. ¡Dejo esto como un ejercicio para ti!

    
respondido por el wil 16.09.2012 - 21:37
fuente
7

OpenGL es una plataforma independiente; eso significa que la API de OpenGL es independiente de la plataforma.

Los estados y buffers de OpenGL son recopilados por un objeto abstracto, comúnmente llamado contexto.

La plataforma de alojamiento es responsable de proporcionar alguna API para crear el contexto OpenGL para la plataforma subyacente. En Windows hay 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 un contexto OpenGL para poder utilizar la API de OpenGL.

Las operaciones WGL / GLX comunes son la creación de una ventana, la creación de un búfer fuera de pantalla, hacer que el contexto de OpenGL sea actual en un hilo, intercambiar búferes de dibujo ...

En cambio, DRI es una capa de kernel que permite la comunicación directa con la tarjeta gráfica, pasando por alto el servidor X, lo que acelera la aplicación usando rutinas OpenGL.

    
respondido por el Luca 17.09.2012 - 16:56
fuente
3

enlace

La Infraestructura de Representación Directa, también conocida como DRI, es un marco para permitir el acceso directo al hardware de gráficos bajo el Sistema X Window de una manera segura y eficiente. Incluye cambios en el servidor X, en varias bibliotecas cliente y en el kernel (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 3D en la especificación DRI, incluidos controladores para conjuntos de chips producidos por 3DFX, AMD (anteriormente ATI), Intel y Matrox.

    
respondido por el KawaiKx 09.03.2014 - 09:30
fuente
2

Para decirlo simplemente, OpenGL es el tipo y especificación de la biblioteca de gráficos. Mesa es una implementacion de base. 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 la forma en que todo se interconecta con X!

Para comprender qué es cada parte, debes saber cómo encaja.

Un programa está diseñado para interactuar con cualquier biblioteca openGL.

GLX es un medio para interactuar con OpenGL 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 de Mesa.

En una configuración indirecta es la siguiente: Marco de la aplicación (es decir, la aplicación escrita, el motor o la API de abstracción) | LibGL | Controlador de mesa | DRI | Hardware

En esta configuración, GLX solo se usa en el lateral para manejar la interconexión entre el uso de GL de su programa y otros programas. Aparte de las llamadas específicas de GLX que se usan 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 usar 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 normalmente quieres.

Para un indirecto es Su marco de aplicación | LibGL (lado del usuario) | Libglx | LibGL (lado X11) | Controlador de hardware Mesa | 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 a los clientes de la red, así como una mayor robustez y una configuración más segura.)

Esta configuración puede funcionar en varias máquinas virtuales que comparten una única tarjeta de video o incluso que acceden a través de una red debido a esto. Algunas formas de memoria compartida o memoria virtual compartida "clonada" se pueden usar 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 sockets de red para interactuar con X11 puede ser lento, al menos introducir latencias en programas bien optimizados y, en el peor de los casos, disminuir drásticamente las tasas de fotogramas en los mal optimizados.

Este es el tipo de configuración que es mejor para los clientes en red, las configuraciones que requieren una seguridad más sólida y las configuraciones en las que múltiples sistemas operativos necesitan compartir hardware ejecutándose a través de la misma pila de GL. Está lejos de ser óptimo, pero le proporciona cierto grado de aceleración de hardware.

    
respondido por el Robert Wm Ruedisueli 12.07.2017 - 05:40
fuente

Lea otras preguntas en las etiquetas