Por lo que parece ahora, cada glSet tiene que incluir glBind (algo) dentro de él
No exactamente. Es al revés, como se describe en varios párrafos a continuación.
Incluso si fuera cierto, recuerde que los comandos GL desde la aplicación cliente al servidor GL (también conocido como controlador) tienen una sobrecarga de despacho en comparación con una llamada de función normal. Incluso si suponemos que las funciones DSA son solo envoltorios alrededor de las funciones existentes, son envoltorios que viven dentro del servidor GL y, por lo tanto, pueden tener (un poco) menos sobrecarga.
si OpenGL sigue siendo una máquina de estado, no puede aprovechar los cambios transmitidos aplicados a un solo elemento.
Las GPU no son máquinas de estado. La interfaz de la máquina de estado GL es una emulación que envuelve elementos internos de controladores similares a DSA, no al revés.
Eliminar una capa de envoltura, una capa que requiere un número excesivo de llamadas en el servidor GL, es claramente una victoria, incluso si es pequeña.
El enfoque de máquina de estado tampoco tiene mucho sentido cuando se trata de múltiples hilos; GL sigue siendo terrible en este caso de uso, pero los controladores a menudo usan hilos detrás de escena, y una máquina de estados requiere mucha sincronización de hilos o algoritmos / construcciones paralelas realmente elegantes para que las cosas funcionen de manera confiable.
La extensión DSA continúa expresando su funcionamiento en términos de cambios de estado porque, después de todo, es una extensión de un documento basado en estado existente y no una API completamente nueva, por lo que tenía que estar lista para conectarse a la especificación GL existente Lenguaje y terminología del documento. Incluso si ese lenguaje existente es muy adecuado para su trabajo como una API moderna de hardware de gráficos.
Explique el razonamiento y las ventajas del nuevo DSA.
El mayor razonamiento es que la vieja forma era un dolor. Hacía muy difícil componer bibliotecas que pudieran modificar o depender del estado GL. Esto dificultó el encapsulado eficiente de la API GL en un estilo orientado a objetos o funcional debido a sus profundas raíces de gestión de estado procesal, lo que dificultó el encapsulamiento de la API en varios lenguajes que no son C y también dificultó proporcionar envoltorios de dispositivos gráficos eficientes ese resumen de OpenGL de Direct3D.
El segundo fue la sobrecarga de la API de máquina de estado procesal, como se describió anteriormente.
En tercer lugar, las funciones de DSA cambiaron la semántica, en su caso, de las API antiguas que permitieron una mayor eficiencia. Las cosas que anteriormente eran mutables se hicieron inmutables, por ejemplo, lo que elimina una gran cantidad de código de contabilidad del servidor GL. Las llamadas de la aplicación pueden enviarse al hardware o validarse antes (o de manera más paralela) cuando el servidor GL no tiene que lidiar con objetos mutables.
-
Se dan justificaciones y explicaciones adicionales en la especificación de extensión EXT_direct_state_access .
-
Los cambios de hardware que son relevantes para el diseño de la API son bastante numerosos.
Recuerde que OpenGL se remonta a 1991. El hardware objetivo no eran las tarjetas gráficas de nivel de consumidor (esas no existían) sino grandes estaciones de trabajo CAD y similares. El hardware de esa época tenía sobres de rendimiento muy diferentes a los actuales; el subprocesamiento múltiple era más raro, los buses de memoria y las CPU tenían menos espacio de velocidad, y la GPU hizo poco más que la representación de triángulo de función fija.
Se agregaron más y más funciones de función fija. Se agregaron varios modelos de iluminación, modos de textura, etc., cada uno necesita su propio estado. El enfoque simple basado en el estado funcionó cuando tenía un puñado de estados. A medida que se agregaron más y más estados, la API comenzó a explotar. La API se volvió más incómoda, pero no se alejó demasiado de los modos de hardware, ya que en realidad se basaban en muchos cambios de estado.
Luego, llegó el hardware programable. El hardware se ha vuelto cada vez más programable, hasta el punto de que ahora admite un pequeño estado, algunos programas proporcionados por el usuario y muchos buffers. Todo ese estado de la era anterior tenía que ser emulado, al igual que todas las características de función fija de esa era estaban siendo emuladas por los controladores.
El hardware también cambió para ser cada vez más paralelo. Esto requirió otros rediseños de hardware que hicieron que los cambios en el estado de los gráficos fueran muy caros. El hardware funciona en grandes bloques de estado inmutable. Debido a estos cambios, el controlador no podía simplemente aplicar cada bit del estado que el usuario configuró inmediatamente, sino que tenía que agrupar los cambios automáticamente y aplicarlos cuando fuera necesario de manera implícita.
El hardware moderno funciona aún más lejos del modelo clásico OpenGL. DSA es un pequeño cambio que se necesitaba hace más de 10 años (originalmente se prometió como parte de OpenGL 3.0), similar a lo que hizo D3D10. Muchos de los cambios de hardware anteriores necesitan mucho más que solo DSA para mantener relevante a OpenGL, por lo que aún están disponibles extensiones más grandes que cambian drásticamente el modelo de OpenGL . Luego está la nueva API GLnext plus D3D12, Mantle, Metal, etc., ninguna de las cuales mantiene la abstracción de la máquina de estado pasada de moda.