Esta pregunta es casi imposible de responder porque OpenGL en sí mismo es solo una API frontal, y siempre que una implementación se adhiera a la especificación y el resultado se ajuste 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, esto es nuevamente imposible de responder en general, ya que un controlador está estrechamente vinculado a alguna pieza de hardware, que nuevamente puede hacer cosas sin importar cómo lo haya diseñado el desarrollador.
Entonces la pregunta debería haber sido: "¿Cómo se ve en promedio detrás de escena de OpenGL y el sistema de gráficos?". Veamos esto de abajo hacia arriba:
En el nivel más bajo hay algún dispositivo gráfico. Hoy en día se trata de GPU que proporcionan un conjunto de registros que controlan su funcionamiento (cuyo registro depende exactamente del dispositivo) tienen algo de memoria de programa para shaders, 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 datos y flujos de comandos.
El controlador de gráficos realiza un seguimiento del estado de las GPU y de todos los programas de aplicación de recursos que hacen uso de la GPU. También se encarga de la conversión o cualquier otro procesamiento de los datos enviados por las aplicaciones (convertir texturas al formato de píxel soportado 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.
Luego está el controlador / biblioteca cliente OpenGL dependiente del controlador. En Windows, esto se carga por proxy a través de opengl32.dll, en sistemas Unix, esto reside en dos lugares:
- Módulo X11 GLX y controlador GLX dependiente del controlador
- y /usr/lib/libGL.so puede contener algunas cosas dependientes del controlador para la representación directa
En MacOS X, este es el "Marco OpenGL".
Es esta parte la que traduce las llamadas OpenGL cómo lo hace en llamadas a las funciones específicas del controlador en la parte del controlador descrita en (2).
Finalmente, la biblioteca API de OpenGL real, opengl32.dll en Windows y en Unix /usr/lib/libGL.so; esto en su mayoría solo pasa los comandos a la implementación de OpenGL propiamente dicha.
No se puede generalizar cómo ocurre la comunicación real:
En Unix, la conexión 3 <-> 4 puede ocurrir a través de Sockets (sí, puede hacerlo, y pasa a través de la red si lo desea) oa través de la memoria compartida. En Windows, la biblioteca de interfaz y el cliente del controlador se cargan en el espacio de direcciones del proceso, por lo que no hay tanta comunicación, sino simples llamadas a funciones y paso de variables / punteros. 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 pasar por ioctl, lectura / escritura o mediante la asignación de memoria al espacio de direcciones del proceso y la configuración de la MMU para activar algún código de controlador siempre que se realicen cambios en esa memoria. Esto es bastante similar en cualquier sistema operativo, ya que siempre tienes que cruzar el límite del kernel / área de usuario: en última instancia, atraviesas una llamada al sistema.
La comunicación entre el sistema y la GPU se realiza a través del bus periférico y los métodos de acceso que define, por lo que PCI, AGP, PCI-E, etc., funcionan a través de Port-I / O, Memory Mapped I / O, DMA, IRQ.