Is OpenGL backward compatible with OpenGL ES?

Question

OpenGL ES claims to be a subset of OpenGL, which theoretically means that any OpenGL ES program can work like regular OpenGL on a PC; however, it seems that OpenGL ES has slightly different naming conventions for some functions ( glOrtho vs glOrthof ). Does it matter? Can the OpenGL ES application still work with the OpenGL GPU either out of the box or with recompilation?

Answer 1

Can the OpenGL ES application still work with the OpenGL GPU either out of the box or with recompilation?

Not. Kinda, but since you raised glOrtho , it means that you are talking about ES 1.x, not 2.x, and not about yourself. ES 3.0 adds some new stuff to the mix; See below for more details.

OpenGL ES 1.x is not a subset of any version of OpenGL. These are quite significant differences. You might perhaps be able to code a common subset, but you would throw a lot to do this. On both platforms.

ES 2.x has much more similarities to the desktop GL 2.1, but it is still not a suitable subset. For example, glTexImage2D has a completely different behavior. On the GL desktop, the last three options do not affect the actual texture format. In ES 2.0, they define the format of the actual texture image. You can write a valid glTexImage2D command that will do the same in ES 2.0 and the desktop GL 2.1, but you drop a lot under the GL desktop to do this (for example, choosing the size of the internal format).

Having said that, you can outline the differences of the API with abstractions. The big problem you'll encounter with ES 2.0 is GLSL.

GLSL ES has added several new keywords, in particular, exact classifiers. The GLSL 1.20 desktop (which combines with GL 2.1) does not have these keywords. GLSL desktop 1.30 and above, but they are tied to GL 3.0 hardware. Therefore, it is difficult to write a shader for ES 2.0, which will work without changes on the desktop equipment GL 2.1.

This, of course, is not insurmountable. A few sensible #defines, which themselves may be # ifdef'd for different languages, can make this pretty simple. But you still need to find all of these cases.

The recently released OpenGL ES 3.0 is also not a suitable subset of OpenGL 3.3, but it is closer to ES 2.0. It is very important that GLSL 3.30 is almost identical to GLSL ES 3.00. This way, you can much more easily exchange shaders between them.

ES 3.0 has certain limitations that are not included in 3.3, but in general they are easy to avoid (and using most of them is bad practice). And some of the features of ES 3.0 are technically not GL 3.3, but they are in the GL 3.3 publicly available base extensions (such as ARB_texture_storage, and there is an ES3_compatibility extension to increase compatibility). But now it’s much easier to work when glTexImage2D works the same way between two cases. Now interop is more about avoiding functionality that is not available to both.

Answer 2

Current versions of OpenGL (4.x) and OpenGL ES (2.x) are similar, although there are enough differences in the fact that the transfer code will not work only by recompiling. As @Nicol Bolas notes, there are many features in OpenGL that are not even present in OpenGL ES, while some APIs behave somewhat differently. In addition, platform support is very different (i.e., setting up a rendering context, etc.).

OpenGL ES 2.0 is actually not backward compatible with 1.x, because the model has changed from the old style of immediate mode (as provided in OpenGL 2.1 and earlier versions) to a more modern model based on shaders.

OpenGL v3 and v4 depreciate many of the anachronistic 2.x features, although the main drivers retain compatibility modes to continue this older support.

The GL_ARB_ES2_compatibility extension in OpenGL 4.x helps bring desktop and mobile editions closer together for easier portability.

Few differences, such as glOrtho vs glOrthof , are obviously easy to manage, but you will need to write wrappers for other functions.