opengl - studio - maquina de moore ejemplos
¿Por qué OpenGL se diseñó originalmente como una máquina de estado? (2)
De http://www.cs.tufts.edu/research/graphics/resources/OpenGL/OpenGL.htm :
La razón por la cual OpenGL funciona como una máquina de estado es para evitar tener que pasar muchos argumentos en cada llamada de función.
Paso mínimo de argumento
La comunicación entre un programa de aplicación y OpenGL finalmente debe pasar a través del bus de datos de la estación de trabajo al hardware de gráficos. El bus de datos suele ser mucho más lento que la CPU de la estación de trabajo y el hardware de gráficos, por lo que a menudo puede ser el cuello de botella en los gráficos de alta velocidad. Para mantener la velocidad más alta posible, OpenGL pasa la menor cantidad de argumentos posible en sus llamadas a funciones, como se puede ver al revisar la documentación de OpenGL. Todas las llamadas suponen que muchas variables internas se han establecido previamente en los valores que desea.
Durante mi experiencia OpenGL, a menudo me olvidé de establecer algunos estados. Así que creo que la máquina de estado puede no ser un buen diseño hoy en día. Pero ahora tiene que ser compatible. Y también sé que DirectX también fue una máquina de estado en los primeros días. Me gustaría saber por qué OpenGL y DirectX fueron diseñados originalmente como una máquina de estado.
No está claro a qué se refieren las personas cuando se refieren a la "máquina de estados", ya que nunca explican qué es lo opuesto. Por lo tanto, hablaré de ello de forma general y específica en términos de OpenGL "máquina de estado" frente a la actual D3D "no una máquina de estados".
Tanto OpenGL como Direct3D usan estado global. Cada comando de representación requiere que establezca un montón de estado.
Para representar en ambas API, debe establecer un grupo de estado global. Tienes que establecer qué sombreadores vas a usar. Tienes que establecer los parámetros actuales con los que deseas usar esos uniformes. Si usa texturas, debe configurarlas. Necesita configurar los parámetros de su ventana gráfica actual. Etcétera.
La razón de este tipo de "máquina de estados" es simple: así es como funciona generalmente el hardware.
Cada bit de estado representa algunos registros en la GPU. Esos registros son estado . Los sombreadores deben cargarse para poder renderizar. Debe configurar los registros de la ventana gráfica. Debe configurar qué registros de direccionamiento de textura está utilizando. Etcétera. Por lo tanto, las API son máquinas de estado porque la GPU es una máquina de estado.
Podrías imaginar que eso se haría con un comando de renderizado. Pero solo mira cuántos objetos necesitarás pasar. Tendría que pasar un montón de sombreadores, un montón de texturas, sus datos de vértice, su framebuffer, la configuración de su viewport, la configuración de su mezcla, etc.
Entonces, en cambio, las API hacen que hagas lo que hace la GPU. Has configurado todo esto de antemano.
Además, esto hace que la API sea más rápida . ¿Por qué? Porque ahora la API sabe qué estado estás usando. Si desea representar, por ejemplo, diferentes partes de una malla con diferentes texturas, puede mantener el framebuffer, viewport, vertex data, etc. de la misma manera. Lo único que cambia entre ellos es qué texturas usa.
Si usó algún tipo de llamada Draw gigante con docenas de parámetros, ahora la API tiene que mirar cada parámetro para ver si es igual a su última llamada al sorteo. Y si no es así, debe actualizar los registros de la GPU.
Ahora, en cuanto a las diferencias entre OpenGL y D3D. En este caso, la diferencia en cuestión es cómo tratan los objetos.
D3D está basado en objetos, en el sentido de que las funciones que modifican objetos toman el objeto como un parámetro. Además, la mayoría de los objetos D3D son inmutables ; una vez que los crea, no puede cambiar la mayoría de sus configuraciones. Una vez que creas una textura de cierto tamaño, formato, etc., ya está hecho. No puede reasignarlo con un tamaño / formato / etc diferente sin eliminar el objeto y crear uno nuevo.
OpenGL está basado en estado. Lo que esto significa es que las funciones de OpenGL que modifican objetos (en su mayor parte) no toman el objeto que operan como parámetros.
Esto no es un "diseño" sino simplemente la estricta adherencia de OpenGL a la compatibilidad con versiones anteriores. Los objetos en OpenGL son solo fragmentos de estado global; así es como están definidos. ¿Por qué?
Porque originalmente, en OpenGL 1.0, no había objetos (además de listas de visualización). Sí, ni siquiera los objetos de textura . Cuando decidieron que esto era estúpido y que necesitaban objetos, decidieron implementarlos de una manera compatible con versiones anteriores. Todos ya estaban usando funciones que operaban en estado global. Entonces, simplemente dijeron que al vincular un objeto, anulas el estado global. Las funciones que solían cambiar el estado global ahora cambian el estado del objeto.
De esta manera, podrían introducir objetos en la API sin introducir también un conjunto de nuevas funciones que solo funcionan con objetos. Por lo tanto, el código que funcionaba antes podría funcionar con objetos con solo ajustes mínimos, en lugar de forzar una reescritura no trivial del código. También significa que si tuvieran que introducir nuevas funciones que toquen texturas, trabajarían con y sin objetos. Por lo tanto, era compatible tanto hacia atrás como hacia adelante.
La mayoría de los objetos OpenGL funcionan de esta manera : si desea cambiarlos, debe vincularlos y luego modificar el estado "global".