¿Cómo soportan las GPU la ejecución de OpenGL y DirectX API?

Question

Estoy tratando de entender cómo funcionan OpenGL y DirectX con la tarjeta gráfica.

Si escribo un programa en OpenGL que haga un triángulo, y otro en DirectX que haga lo mismo, ¿qué pasa exactamente con el lado de la GPU?

¿Cuando ejecutamos el programa, cada llamada a la biblioteca de OpenGL y cada llamada a la biblioteca DirectX producirán código para la GPU, y el código de máquina de la GPU producido a partir de los dos programas será el mismo? (Al igual que si DirectX y OpenGL son como código de bytes Java, precompilados, cuando se está ejecutando, producen lo mismo)

¿O la GPU tiene 2 conjuntos de instrucciones diferentes, uno para cada uno? Quiero decir, ¿qué es exactamente OpenGL y DirectX para la GPU, cómo puede hacer la diferencia entre las 2 API?

¿Es esto solo diferente de la perspectiva del programador?

Answer 1

ya me contestaron que están aquí On Windows, how does OpenGL differ from DirectX?

cita completa de una de las respuestas sigue

---

Esta pregunta es casi imposible de contestar porque OpenGL por sí mismo es sólo un API de extremo frontal, y mientras como una implementación se adhiere a la especificación y el resultado se ajusta a esto, se puede hacer de la forma que desee.

La pregunta puede haber sido: ¿Cómo funciona un controlador OpenGL en el nivel más bajo. Ahora, de nuevo, esto es imposible de responder en general, ya que un controlador está estrechamente ligado a alguna pieza de hardware, lo que puede volver a hacer las cosas, sin embargo, el desarrollador lo diseñó.

Así que la pregunta debería haber sido: "¿Cómo se ve en promedio detrás de las escenas de OpenGL y el sistema de gráficos?". Veamos esto de abajo hacia arriba:

1. En el nivel más bajo hay algunos dispositivos gráficos. Hoy en día, estas son GPU que proporcionan un conjunto de registros que controlan su funcionamiento (cuyos registros dependen exactamente del dispositivo) tienen alguna memoria de programa para sombreadores, memoria masiva para datos de entrada (vértices, texturas, etc.) y un canal de E/S para el resto del sistema sobre el que recibe/envía flujos de datos y comandos.

2. El controlador de gráficos realiza un seguimiento del estado de las GPU y de todos los programas de aplicaciones de recursos que hacen uso de la GPU. También es responsable de la conversión o cualquier otro procesamiento de los datos enviados por las aplicaciones (convertir texturas en el formato de pixel admitido por la GPU, compilar sombreadores en el código máquina de la GPU). Además, proporciona una interfaz abstracta, dependiente del controlador, para los programas de aplicación.

3. Luego está la biblioteca/controlador del cliente OpenGL dependiente del controlador. En Windows esto se cargado por poder a través Opengl32.dll, en los sistemas Unix esto reside en dos lugares:

   • módulo X11 GLX y el controlador de controlador GLX dependiente
   • y /usr/lib/libGL.so puede contener algunas cosas dependientes del controlador para la representación directa

   En MacOS X, este es el "Framework OpenGL".

   Esta es la parte que traduce las llamadas de OpenGL cómo lo hace en las llamadas a las funciones específicas del controlador en la parte del controlador descrita en (2).

4. Finalmente, la biblioteca de la API de OpenGL real, opengl32.dll en Windows, y en Unix /usr/lib/libGL.so; esto solo pasa los comandos a la implementación de OpenGL propiamente dicha.

cómo sucede no se puede generalizar la comunicación real:

En Unix el 3 < - Conexión> 4 puede ocurrir ya sea a través de sockets (sí, puede, y lo hace ir a través de la red si desea) o a través de la memoria compartida. En Windows, tanto la biblioteca de la interfaz como el cliente del controlador se cargan en el espacio de direcciones del proceso, de modo que no se trata tanto de comunicación sino de llamadas a funciones simples y paso variable/de puntero. En MacOS X esto es similar a Windows, solo que no hay separación entre la interfaz OpenGL y el cliente del controlador (esa es la razón por la que MacOS X es tan lento para mantenerse al día con las nuevas versiones de OpenGL, siempre requiere una actualización completa del sistema operativo para entregar el nuevo marco de referencia).

La comunicación entre 3 < -> 2 puede ir a través de ioctl, lectura/escritura o asignando memoria en el espacio de direcciones de proceso y configurando la MMU para activar algún código de controlador cada vez que se realizan cambios en esa memoria. Esto es bastante similar en cualquier sistema operativo ya que siempre debe cruzar el límite kernel/userland: en última instancia, pasa por algunos syscall.

La comunicación entre el sistema y la GPU ocurre a través del bus periférico y los métodos de acceso que define, así que PCI, AGP, PCI-E, etc., que funcionan a través de E/S de puertos, E/S asignadas de memoria, DMA, IRQ .