Versiones OpenGL y gpus: ¿qué tipo de compatibilidad hay?

Question

Estoy tratando de entender cómo funcionan las versiones de las tarjetas gráficas, las versiones OpenGL y los encabezados API. He leído sobre la debacle de OpenGL 2.0/3.0/3.1 en los foros de OpenGL y en otros lugares, pero todavía no está claro cómo me funcionará esto como desarrollador (nuevo en OpenGL). (Por cierto, estoy usando nVidia en esta pregunta como ejemplo porque estoy comprando una de sus tarjetas, pero obviamente me gustaría ser independiente del fabricante para el software que desarrollo).

Primero, está la GPU que necesita admitir una versión OpenGL. Pero, p. nVidia tiene controladores para tarjetas de video antiguas para admitir OpenGL 3. ¿Eso significa que estos controladores implementan ciertas funcionalidades en el software para emular nuevas funcionalidades que no están en el hardware?

Luego están los encabezados de la API. Si decido escribir una aplicación para OpenGL 3, ¿debo esperar hasta que Microsoft lance una versión actualizada de la plataforma SDK con encabezados compatibles con esta versión? ¿Cómo se selecciona qué versión de la API usar? Mediante un preprocesador definir en el código, o la actualización a la última plataforma SDK simplemente actualiza a lo que sea la última versión (no puedo imaginar esta última opción, pero nunca se sabe. ..).

¿Qué tal compatibilidad con versiones anteriores? Si escribo una aplicación orientada a OpenGL 1.2, ¿podrán los usuarios que hayan instalado los controladores de su tarjeta compatible con OpenGL 3 ejecutar o debo probar las características de la tarjeta/versión soportada en mi aplicación? La lectura http://developer.nvidia.com/object/opengl_3_driver.html parece confirmar que, al menos para las tarjetas nVidia, las aplicaciones escritas contra 1.2 continuarán funcionando, pero esto también implica que otros proveedores pueden dejar de admitir 1.2 API. Básicamente eso me pondría (potencialmente) en una posición en el futuro donde el software no funcionaría con tarjetas recientes porque ya no son compatibles con 1.2. Pero si desarrollo para OpenGL 3 o incluso 2 hoy, puedo excluir a los usuarios que solo son compatibles con GPU 1.2.

No necesito las características sofisticadas en OpenGL - Apenas uso sombreado, la tubería fija funciona bien para mí (mi aplicación es similar a CAD). ¿Cuál es la mejor versión para basar una nueva aplicación, con la expectativa de que será una aplicación de larga duración con actualizaciones incrementales en los próximos años?

Probablemente estoy olvidando otros problemas que son relevantes en este contexto, cualquier idea es muy apreciada.

Answer 1

Desde mi experiencia OpenGL, parece que "orientar" una versión determinada es simplemente acceder a las diversas extensiones que se han agregado para esa versión. Por lo tanto, la única razón por la que "orientará" a OpenGL versión 3 es si desea utilizar algunas de las extensiones nuevas en la versión 3. Si realmente no usa extensiones de la versión 3 (si solo está haciendo cosas básicas de OpenGL) , entonces, naturalmente, no estás "dirigiendo" la versión 3.

En Visual Studio, siempre vinculará su aplicación con opengl32.lib, y opengl32.lib no cambia en las diferentes versiones de OpenGL. En su lugar, OpenGL utiliza wglGetProcAddress() para acceder dinámicamente a las extensiones/versiones de OpenGL en tiempo de ejecución en lugar de en tiempo de compilación. A saber, si un controlador dado no es compatible con una extensión, entonces wglGetProcAddress() devolverá NULL en tiempo de ejecución cuando se solicite el procedimiento de esa extensión. Por lo tanto, en su código necesitará implementar una lógica que maneje el caso de devolución NULL. En el escenario más simple, puede imprimir un error y decir "esta función no está disponible, por lo que este programa se comportará ...". O puede encontrar otros métodos alternativos para hacer lo mismo que no usa la extensión. En su mayor parte, solo obtendrá retornos NULL de wglGetProcAddress si su aplicación se ejecuta en hardware/controladores antiguos que no son compatibles con la versión de OpenGL que agregó la extensión que está buscando. Sin embargo, en los próximos años, querrá mantenerse al tanto de las cosas que las versiones más nuevas de OpenGL deciden desaprobar. No he leído demasiado en la especificación 3.1, pero aparentemente están introduciendo un modelo de desaprobación en el que las tecnologías/extensiones antiguas pueden estar en desuso, lo que abrirá la puerta para que los nuevos controladores/hardware ya no admitan extensiones obsoletas, en cuyo caso wglGetProcAddress devolverá NULL nuevamente para esas extensiones. Entonces, si pones la lógica para manejar el retorno NULL en wglGetProcAddress(), aún así estarás bien incluso para las extensiones obsoletas. Puede ser necesario que implemente mejores alternativas o que establezca nuevas extensiones predeterminadas.

En cuanto a los encabezados de la API versionada, los cambios en los encabezados son en su mayoría solo cambios para permitir el acceso a nuevas funciones devueltas por wglGetProcAddress(). Entonces, si incluye el encabezado API para la versión 2, puede continuar siempre y cuando solo necesite las extensiones para OpenGL 2. Si necesita acceder a las funciones/extensiones que se agregaron en la versión 3, simplemente debe reemplazar su versión 2 encabezado con el encabezado de la versión 3, que solo agrega algunos punteros de tipo de función adicional asociados con las nuevas extensiones, de modo que cuando llame a wglGetProcAddress(), puede convertir el valor de retorno en el puntero de función correcto. Ejemplo:

PFNGLGENQUERIESARBPROC glGenQueriesARB = NULL; 

... 

glGenQueriesARB = (PFNGLGENQUERIESARBPROC)wglGetProcAddress("glGenQueriesARB"); 

En el ejemplo anterior, el typedef para PFNGLGENQUERIESARBPROC se define en las cabeceras API. glGenQueriesARB se agregó en 1.2, creo, así que necesitaría al menos los encabezados de 1.2 API para obtener la definición de PFNGLGENQUERIESARBPROC. Eso es realmente lo que hacen todos los encabezados.

Una cosa más que quiero mencionar sobre 3.1. Al parecer, con 3.1 están desaprobando muchas funcionalidades de OpenGL que mi empresa ha utilizado de manera ubicua, incluidas las listas de visualización, los mecanismos glBegin/glEnd y el modo de renderizado GL_SELECT. No sé mucho sobre los detalles, pero no veo cómo pueden hacerlo sin tener que crear un nuevo archivo opengl32.lib para vincular, porque parece que la mayoría de esa funcionalidad está integrada en opengl32.lib, y no se accede a través de wglGetProcAddress. Además, ¿Microsoft va a incluir ese nuevo archivo opengl32.lib en sus versiones de Visual Studio? No tengo una respuesta para esas preguntas, pero creo que, aunque 3.1 lo desaproveche, esta funcionalidad va a durar mucho tiempo. Si continúa enlazando con su opengl32.lib actual, debería continuar funcionando casi indefinidamente, aunque puede perder aceleración de hardware en algún momento. La gran mayoría de los tutoriales de OpenGL disponibles en la web usan los métodos glBegin/glEnd para dibujar primitivos. Lo mismo es cierto para GL_SELECT, aunque una gran cantidad de hardware ya no acelera el modo de renderizado GL_SELECT. Incluso el tutorial de opengl.org usa los métodos glBegin/glEnd supuestamente desaprobados. Y todavía tengo que encontrar un tutorial de "introducción" que solo utilice las características 3.1, evitando la funcionalidad en desuso (sin duda, si alguien conoce una, vincúleme a ella). De todos modos, aunque parece que 3.1 ha tirado mucho de lo viejo para todas las cosas nuevas, creo que las cosas viejas seguirán existiendo por bastante tiempo.

En resumen, este es mi consejo. Si sus necesidades de OpenGL son simples, solo use la funcionalidad básica de OpenGL. Las matrices de vértices son compatibles con las versiones 1.1 - 3.1, así que si estás buscando la máxima vida útil y estás empezando de nuevo, eso es probablemente lo que deberías usar. Sin embargo, mi opinión es glBegin/glEnd y las listas de visualización seguirán existiendo por un tiempo a pesar de que están en desuso en la versión 3, así que si quieres usarlas, no me preocuparé demasiado. Evitaría el modo GL_SELECT para elegir un método alternativo. Muchos de los proveedores de hardware han considerado a GL_SELECT como obsoleto desde hace años, a pesar de que acaba obsoleto con la versión 3. En nuestra aplicación obtenemos muchos problemas donde no funciona en las tarjetas ATI y las tarjetas GMA integradas. Posteriormente, implementamos un método de selección que utiliza consultas de oclusión que parece solucionar el problema. Entonces, para hacerlo bien la primera vez, evite GL_SELECT.

Buena suerte.

Answer 2

En cuanto a los controladores, creo que en algunos casos falta la funcionalidad escrito en el software. El objetivo de usar OpenGL (aparte de la aceleración) es escribir en una API y no importar cómo se implementa.

En mi experiencia, no declaras las versiones OpenGL. Las llamadas a funciones entre versiones de API no se solapan. Tenga en cuenta la especificación y si, por ejemplo, llama a un método 2.0, la versión mínima de su aplicación acaba de convertirse en 2.0. Tengo aplicaciones de visualización escritas para apuntar a OpenGL (estúpidas viejas tarjetas de video Sun) y funciona muy bien en las nuevas tarjetas de la serie nvidia 200.

No creo que haya ninguna forma de garantizar que una API no cambie en el futuro; especialmente si no lo controlas Su aplicación puede dejar de funcionar en 10 años cuando tengamos OpenGL 6.4. Esperemos que haya escrito una aplicación lo suficientemente buena como para que los clientes estén dispuestos a pagar por una actualización.

Answer 3

Este tipo, MarK J. Kilgard ha estado publicando código fuente nVidia y documentos en openGL desde los años 90 y lo ha estado haciendo en nombre de uno de los dos nombres más importantes en el hardware de juegos.

// -------------------------------------------- ----------------------------------------- ... la noción de que una aplicación OpenGL es "incorrecta" para usar el modo inmediato es demasiado entusiasta. La especificación OpenGL 3.0 incluso ha llegado al punto de marcar el modo inmediato en OpenGL para "desaprobar" (¡lo que sea que eso signifique!); tal extremismo es contraproducente y tonto. La forma correcta de alentar el buen uso de API no es tratar de desaprobar o prohibir el uso de API, sino educar a los desarrolladores sobre el uso correcto de API para situaciones particulares.