OpenGL 3.0 y 3.1 han dejado de lado bastantes características que considero esenciales. En particular, el uso de la función fija en sombreadores.OpenGL: ¿Cuál es el problema con la depreciación?
¿Alguien puede explicar de qué se trata realmente?
¿Por qué encuentran la necesidad de desaprobar una función tan útil que es obvio que todo el mundo usa y que ninguna compañía de hardware en sí va a quitar soporte?
Como ha dicho, ninguna empresa de hardware eliminará el soporte para sombreadores de función fija, porque hay tantas aplicaciones existentes que los usan. Lo que no quieren hacer, sin embargo, es averiguar cómo especificar las interacciones entre los sombreadores FF y cada extensión futura que agreguen. Esas interacciones son muy complicadas (en parte porque los sombreadores FF son tan complicados), lo que genera errores y implementaciones inconsistentes entre los proveedores, las cuales son malas para los desarrolladores y los usuarios finales.
Por lo tanto, están trazando una línea: si desea utilizar los sombreadores FF, no obtendrá ninguna de las nuevas funciones. Si desea una nueva funcionalidad, no puede usar sombreadores FF. Esto es muy similar a lo que hizo Microsoft en D3D10: agregó un montón de nuevas funcionalidades, pero al mismo tiempo eliminó por completo los sombreadores de función fija. La creencia es que el conjunto de desarrolladores que necesitan la nueva funcionalidad sin sombreador pero que no necesitan también sombreadores programables es muy pequeño.
Los sombreadores de funciones fijas se reemplazan bastante fácilmente con sombreadores GLSL estándar, por lo que es difícil ver por qué lógicamente no deberían ser desaprobados.
Estoy menos seguro que usted de que no se eliminarán de mucho hardware en el futuro previsible ya que OpenGL ES 2.0 no es compatible con la tubería FF (por lo que no es compatible con OpenGL ES 1.x) Me parece que gran parte del impulso con OpenGL en estos días proviene de la adopción generalizada de OpenGL ES en plataformas móviles y, con la funcionalidad FF, a partir de ahí habrá una considerable presión para alejarse de su uso.
De hecho, esperaría que la implementación más simple de OpenGL ES para reemplazar OpenGL estándar ampliamente en los próximos años, y la funcionalidad FF puede desaparecer más porque la mayoría de hardware implementará OpenGL ES en lugar de porque se elimina del hardware que implementa el OpenGL completo
Se debe aclarar que una característica que está marcada como "obsoleta" no se elimina realmente. Por ejemplo, un contexto OpenGL 3.0 tiene todas las características: nada se ha ido. Además, algunos proveedores enviarán controladores que pueden crear contextos 3.1 y 3.2 utilizando un perfil de compatibilidad que también habilitará las características en desuso. Por lo tanto, observe de cerca qué hardware de proveedor va a admitir y pregunte sobre el modo de compatibilidad ARB para las características anteriores. (También existe el perfil "central" a partir de 3.2, que permite a los proveedores crear un controlador más pobre y malo si desean hacer tal cosa)
Tenga en cuenta que cualquier tarjeta actual realmente no tiene un hardware FF sección más, solo ejecutan sombreadores. Cuando pide el comportamiento FF, el tiempo de ejecución GL es autoría de shaders en su nombre ..
¿Por qué se encuentran la necesidad de despreciar tal característica útil que su obvia todo el mundo utiliza y que ninguna compañía de hardware en su sano juicio va a quitar ¿apoyo para?
supongo entonces Apple debe estar loco, porque MacOSX 10.7 soporta sólo el 3,2 núcleo. Sin soporte de especificaciones de compatibilidad, sin extensión de compatibilidad ARB, nada. Puede crear un contexto 2.1 o un contexto básico 3.2.
Sin embargo, si desea razones:
En aras de la exhaustividad: lo que dijo Jesse Hall. El ARB ya no tiene que considerar la interacción entre la función fija y las nuevas características. Las matemáticas enteras, las texturas de matriz y varias otras características están definidas para no ser utilizables con la interconexión de funciones fija. OpenGL realmente ha mejorado en los últimos 3 años desde que salió GL 3.0; el ritmo de los cambios del ARB es bastante sustancial. ¿Habría sido posible si tuvieran que encontrar la manera de hacer que todas esas características interactúen con la función fija? Y si no tenían interacciones de funciones fijas, ¿no se estaría quejando entonces de que no puede acceder a las nuevas funciones desde su código anterior? Que conduce muy bien en:
Sirve como una fuerte indicación de lo que uno debe estar utilizando. Incluso si el contexto de compatibilidad está siempre disponible, puede consultar OpenGL central para ver cómo se debe estar abordando la resolución de problemas.
Hace que la eventual unificación de escritorios GL y GL ES sea mucho más razonable. ES 2.0 descartó todas las cosas viejas y acaba de adoptar lo que podrías pensar como núcleo GL 2.1. El objetivo final será tener solo un OpenGL. Para hacer eso, debes poder eliminar el GL de escritorio de todos los cruft.
OpenGL permite tanto un perfil de "núcleo" como un perfil de "compatibilidad". Entonces, para la mayoría de los sistemas, no perderá ningún tipo de acceso a las funciones obsoletas o eliminadas.
Pero si quieres asegurarte de que sea compatible, es mejor que te mantengas en el núcleo. No se le garantizará un perfil de compatibilidad (incluso si la mayoría del hardware tiene uno y en el estado actual es más probable que encuentre un OpenGL desactualizado en lugar de uno solo central). También OpenGL ES ahora es un subconjunto de OpenGL, es posible escribir un programa OpenGL ES 2.x/3.x y ejecutarlo en OpenGL 4.3 casi sin cambios.
Consola de juego como las PlayStations y las de Nintendo enviadas con sus propias bibliotecas de gráficos en lugar de usar OpenGL.
Se basaban en OpenGL pero aquí se desglosaron de forma similar a ES (no creo que ES 2.0 hubiera salido). Esos sistemas necesitan escribir sus propios controladores de gráficos y bibliotecas, pedirle a un proveedor de hardware que escriba lo que es básicamente una carga completa de bibliotecas de envoltura heredadas es un poco demasiado (todas las funciones fijas terminarían siendo implementadas en sombreadores en algún momento y es probable que glBegin/glEND solo se convierta en un VBO automáticamente de todos modos).
Creo que también ha sido importante asegurarse de que los desarrolladores conozcan la forma actual en que deberían programar. Durante décadas, a las personas se les ha enseñado la forma "incorrecta" de hacer las cosas de forma predeterminada y los objetos de búfer de vértice se han enseñado como un extra.
"el tiempo de ejecución GL está creando sombreadores en su nombre." .... ¿Tiene alguna referencia para eso? – shoosh
No fuera de mi cabeza. Solo conversaciones con conductores de IHV. –
Vea también: http://developer.nvidia.com/object/opengl_driver.html – Stringer