Is OpenGL backwards compatible with OpenGL ES?

Question

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

Answer 1

Can an OpenGL ES app still work with an OpenGL GPU/driver out of the box or with only a recompilation?

No. Kinda, but since you brought up glOrtho, which means you're talking about ES 1.x rather than 2.x, not for you. ES 3.0 adds some new stuff to the mix; see the bottom for details.

OpenGL ES 1.x is not a subset of any version of OpenGL. They are some pretty significant differences. You might, might be able to code to a common subset, but you'd be throwing away a lot to do it. On both platforms.

ES 2.x shares far more similarities with desktop GL 2.1, but it still isn't a proper subset. For example glTexImage2D has radically different behavior. Under desktop GL, the last three parameters do not affect the actual format for the texture. Under ES 2.0, they are what defines the texture's actual image format. You can write a valid glTexImage2D command that will do the same thing under ES 2.0 and desktop GL 2.1, but you're throwing away a lot under desktop GL to do it (like picking a sized internal format).

That being said, you can generally cordon off the API differences with abstractions. The big problem you're going to run into with ES 2.0 is GLSL.

GLSL ES added several new keywords, specifically precision qualifiers. Desktop GLSL 1.20 (which pairs with GL 2.1) doesn't have those keywords. Desktop GLSL 1.30 and greater do, but those are bound to GL 3.0 hardware. So it's difficult to write a shader for ES 2.0 that will run unmodified on desktop GL 2.1 hardware.

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

The recently released OpenGL ES 3.0 is not a proper subset of OpenGL 3.3 either, but it is rather closer than ES 2.0. The really important thing is that GLSL 3.30 is almost identical to GLSL ES 3.00. So you can much more easily interchange shaders between the two.

There are certain limits in ES 3.0 that aren't in 3.3, but generally these are easily avoidable (and using most of them is bad practice anyway). And some of the features of ES 3.0 aren't technically in GL 3.3, but they are in commonly-available core extensions to GL 3.3 (such as ARB_texture_storage, and there's the ES3_compatibility extension to increase compatibility). But it's a lot easier to work with now that glTexImage2D actually works the same way between the two cases. Now, interop is more a matter of avoiding functionality not available to both.

Answer 2

The current versions of OpenGL (4.x) and OpenGL ES (2.x) are similar, though there are enough differences that porting code would not work just by recompiling. As @Nicol Bolas points out, there are many features in OpenGL that are not even present in OpenGL ES, while some APIs behave slightly differently. Also, the platform support is very different (ie. setting up a rendering context, etc).

OpenGL ES 2.0 is not actually backward compatible with 1.x, as the model changed from the old immediate-mode style (as enshrined in OpenGL 2.1 and earlier) to the more modern shader-based model.

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

The GL_ARB_ES2_compatibility extension in OpenGL 4.x helps bring the desktop and mobile editions closer together to ease portability.

Minor differences like glOrtho vs glOrthof are obviously easy to manage, but you will need to write wrappers for other features.