2012-04-27 13 views
6

OpenGL ES afirma ser un subconjunto de OpenGL, lo que teóricamente significa que cualquier programa OpenGL ES puede ejecutarse como OpenGL regular en una PC; sin embargo, parece que OpenGL ES tiene convenciones de nomenclatura ligeramente diferentes para algunas funciones (glOrtho vs glOrthof). ¿Esto importa? ¿Puede una aplicación OpenGL ES funcionar aún con una GPU/controlador OpenGL de fábrica o solo con una recompilación?¿Es OpenGL compatible con versiones anteriores de OpenGL ES?

Respuesta

9

¿Puede una aplicación OpenGL ES funcionar aún con una GPU/controlador OpenGL fuera de la caja o con solo una recompilación?

Un poco, pero ya que usted plantea glOrtho, lo que significa que está hablando ES 1.x en lugar de 2.x, no para usted. ES 3.0 agrega algunas cosas nuevas a la mezcla; mira la parte inferior para más detalles.

OpenGL ES 1.x no es un subconjunto de ninguna versión de OpenGL. Son algunas diferencias bastante significativas. Es posible que podría ser capaz de codificar a un subconjunto común, pero estaría tirando mucho para hacerlo. En ambas plataformas.

ES 2.x comparte muchas más similitudes con el escritorio GL 2.1, pero todavía no es un subconjunto adecuado. Por ejemplo, glTexImage2D tiene un comportamiento radicalmente diferente. En el escritorio GL, los últimos tres parámetros no afectan el formato real de la textura. En ES 2.0, son lo que define el formato de imagen real de la textura. Puede escribir un comando glTexImage2D válido que hará lo mismo en ES 2.0 y desktop GL 2.1, pero está tirando mucho en el escritorio GL para hacerlo (como elegir un formato interno de tamaño).

Dicho esto, generalmente puede acotar las diferencias API con abstracciones. El gran problema con el que te vas a encontrar con ES 2.0 es GLSL.

GLSL ES agregó varias palabras clave nuevas, específicamente calificadores de precisión. Desktop GLSL 1.20 (que se empareja con GL 2.1) no tiene esas palabras clave. Desktop GLSL 1.30 y mayor do, pero esos están destinados a GL 3.0 hardware. Por lo tanto, es difícil escribir un sombreador para ES 2.0 que se ejecutará sin modificaciones en el hardware de escritorio GL 2.1.

Esto no es insuperable, por supuesto. Unas # definiciones juiciosas, que sí pueden # ifdef'd para los diferentes idiomas, pueden hacerlo bastante simple. Pero aún tienes que encontrar todos estos casos.

El recientemente lanzado OpenGL ES 3.0 tampoco es un subconjunto adecuado de OpenGL 3.3, pero está bastante más cerca que ES 2.0. Lo realmente importante es que GLSL 3.30 es casi idéntico a GLSL ES 3.00. Entonces puedes intercambiar sombreadores mucho más fácilmente entre los dos.

Existen ciertos límites en ES 3.0 que no están en 3.3, pero generalmente son fácilmente evitables (y usar la mayoría de ellos es una mala práctica). Y algunas de las características de ES 3.0 técnicamente no están en GL 3.3, pero están en extensiones centrales comúnmente disponibles para GL 3.3 (como ARB_texture_storage, y existe la extensión ES3_compatibility para aumentar la compatibilidad). Pero es mucho más fácil trabajar ahora que glTexImage2D funciona de la misma manera entre los dos casos. Ahora, la interoperabilidad es más una cuestión de evitar la funcionalidad que no está disponible para ambos.

4

Las versiones actuales de OpenGL (4.x) y OpenGL ES (2.x) son similares, aunque hay suficientes diferencias como para que el código de portado no funcione simplemente mediante la recompilación. Como señala @Nicol Bolas, hay muchas características en OpenGL que ni siquiera están presentes en OpenGL ES, mientras que algunas API se comportan de forma ligeramente diferente. Además, el soporte de la plataforma es muy diferente (es decir, la configuración de un contexto de representación, etc.).

OpenGL ES 2.0 no es realmente compatible con 1.x, ya que el modelo cambió del antiguo estilo de modo inmediato (como se describe en OpenGL 2.1 y versiones anteriores) al modelo más moderno basado en sombreado.

OpenGL v3 y v4 desestiman muchas características 2.x anacrónicas, aunque los controladores principales retienen los modos de compatibilidad para continuar con este soporte anterior.

El GL_ARB_ES2_compatibility extension en OpenGL 4.x ayuda a acercar las ediciones de escritorio y móviles para facilitar la portabilidad.

Las diferencias menores como glOrtho vs glOrthof son obviamente fáciles de administrar, pero tendrá que escribir envoltorios para otras características.

+0

"Las versiones actuales de OpenGL (4.x) y OpenGL ES (2.x) son muy similares, y compatibles en gran medida" Claro que sí. Si en realidad * no usa * ninguna de las funciones de la publicación 2.1. Al igual que las texturas de enteros, los objetos de buffer uniformes, los objetos de shadow_shader, los sombreadores avanzados (geometría y teselación), puedo seguir pero mi punto es claro. Son solo similares si * anulas * el código de tu GL de escritorio. –

+2

Gracias por la corrección. Actualicé lo anterior en consecuencia, así que espero que sea ahora. También voté tu respuesta. – gavinb