OpenGL è retrocompatibile con OpenGL ES?

Question

OpenGL ES afferma di essere un sottoinsieme di OpenGL, che in teoria significa che qualsiasi programma OpenGL ES può essere eseguito come OpenGL regolare su un PC; tuttavia, sembra che OpenGL ES abbia convenzioni di denominazione leggermente diverse per alcune funzioni (glOrtho rispetto a glOrthof). Questo importa? Un'app OpenGL può ancora funzionare con una GPU/driver OpenGL pronta all'uso o con una sola ricompilazione?

Answer 1

Un'app OpenGL ES può ancora funzionare con una GPU/driver OpenGL pronta all'uso o con una sola ricompilazione?

n Kinda, ma dal momento che ti ha portato fino glOrtho, il che significa che si sta parlando di ES 1.x, piuttosto che 2.x, non per voi. ES 3.0 aggiunge alcune novità al mix; vedere il fondo per i dettagli.

OpenGL ES 1.x non è un sottoinsieme di alcuna versione di OpenGL. Sono alcune differenze piuttosto significative. Potresti, potrebbe essere in grado di codificare in un sottoinsieme comune, ma stai buttando via molto per farlo. Su entrambe le piattaforme

ES 2.x condivide molte più somiglianze con il desktop GL 2.1, ma non è ancora un sottoinsieme appropriato. Ad esempio glTexImage2D ha un comportamento radicalmente diverso. Sotto GL desktop, gli ultimi tre parametri non influenzano il formato effettivo per la trama. Sotto ES 2.0, sono ciò che definisce il formato dell'immagine reale della trama. Puoi scrivere un comando valido glTexImage2D che farà la stessa cosa in ES 2.0 e nel desktop GL 2.1, ma stai buttando via molto da desktop GL per farlo (come scegliere un formato interno di dimensioni).

Detto questo, in genere è possibile isolare le differenze API con le astrazioni. Il grosso problema che incontrerai con ES 2.0 è GLSL.

GLSL ES ha aggiunto diverse nuove parole chiave, in particolare i qualificatori di precisione. Il desktop GLSL 1.20 (che corrisponde a GL 2.1) non ha queste parole chiave. Desktop GLSL 1.30 o superiore do, ma questi sono vincolati all'hardware GL 3.0 . Quindi è difficile scrivere uno shader per ES 2.0 che verrà eseguito senza modifiche sull'hardware GL 2.1 desktop.

Questo non è insormontabile ovviamente. Alcuni #defines giudiziosi, che a loro volta possono essere # ifdef'd per le diverse lingue, possono renderlo abbastanza semplice. Ma devi ancora trovare tutti questi casi.

Il recente OpenGL ES 3.0 non è un sottoinsieme appropriato di OpenGL 3.3, ma è piuttosto più vicino di ES 2.0. La cosa veramente importante è che GLSL 3.30 è quasi identico a GLSL ES 3.00. In questo modo è più facile scambiare gli shader tra i due.

Ci sono certi limiti in ES 3.0 che non sono in 3.3, ma generalmente questi sono facilmente evitabili (e l'uso della maggior parte di essi è comunque una cattiva pratica). E alcune delle caratteristiche di ES 3.0 non sono tecnicamente in GL 3.3, ma sono nelle estensioni core comunemente disponibili a GL 3.3 (come ARB_texture_storage, e c'è l'estensione ES3_compatibility per aumentare la compatibilità). Ma è molto più facile lavorare con ora che lo glTexImage2D funziona effettivamente allo stesso modo tra i due casi. Ora, interop è più una questione di evitare funzionalità non disponibili per entrambi.

Answer 2

Le versioni correnti di OpenGL (4.x) e OpenGL ES (2.x) sono simili, anche se ci sono abbastanza differenze che il porting del codice non funzionerebbe solo ricompilando. Come sottolinea @Nicol Bolas, ci sono molte funzionalità in OpenGL che non sono nemmeno presenti in OpenGL ES, mentre alcune API si comportano in modo leggermente diverso. Inoltre, il supporto della piattaforma è molto diverso (ad esempio, l'impostazione di un contesto di rendering, ecc.).

OpenGL ES 2.0 non è effettivamente compatibile con versioni precedenti 1.x, in quanto il modello è stato modificato dal vecchio stile in modalità immediata (come sancito in OpenGL 2.1 e versioni precedenti) nel modello più moderno basato su shader.

OpenGL v3 e v4 deprecano molte funzionalità anacheroniche 2.x, sebbene i driver principali mantengano le modalità di compatibilità per continuare questo supporto precedente.

Il GL_ARB_ES2_compatibility extension in OpenGL 4.x consente di avvicinare le versioni desktop e mobile per facilitare la portabilità.

Differenze minori come glOrtho vs glOrthof sono ovviamente facili da gestire, ma è necessario scrivere wrapper per altre funzionalità.