- Precision qualifiers were added to GLSL 1.30 to aid portability.
True, and in GLSL 1.30 the meaning of precision qualifies is nothing, i.e. they are ignored. You do get source level compatibility, but the need to carefully choose the precision qualifier in a fragment shader under most GLES2 implementations cannot be understated.
On the subject of shaders, writing to gl_FragDepth is NOT in GLES2… there is the extension GL_EXT_frag_depth to give that back, but it is not a popular extension.
- Some GLES2 commands are more restricted than their GL counterparts, but that doesn’t really make it harder to write portable code. Just target GLES2 first.
This is mostly true, but there are some serious exceptions. The most serious one is glTexImage2D/glTexSubImage2D. In GLES2, the 3rd argument (internalFormat) must be one of GL_ALPHA, GL_LUMINANCE, GL_LUMINANCE_ALPHA, GL_RGB or GL_RGBA, i.e. it states the number of channels and the interpretation of the channels. In contrast, in GL, that argument can be used to precisely state how the texture is stored (ala GL_RGB8, GL_RGB565, in addition to floating point and integer textures). In GLES2, the “internal storage format” of a texture is set by the arguments type and format (7th and 8th argument) of glTexImage2D. The bigger pain comes into play when using the floating point texture extension of GLES2.
Another little irritations are that some GL API points use doubles (usually really clampd) but GLES2 only supports float (which does make since really).
Other annoyances include glGenerateMipmap… even if a GLES2 implementation supports GL_OES_texture_npot, glGenerateMipmap does not work for non-power-of-2 textures (atleast for those tightly conforming to spec). Indeed, SGX and Mali will generate an error on calling glGenerateMipmap on a non-power-2 texture even though both support GL_OES_texture_npot.
On the subject of GLSL programs, under desktop GL one can attach many shaders of the same type to one GLSL program, where as under GLES2 one can attach only one shader of each type. This is not really a big deal, but it is worth noting. Additionally, the binary shader API between GL4 and GLES2 is different; GL4 is at the GLSL program level where as GLES2 is at the shader level. Just to make life more complicated there is also GL_OES_get_program_binary which gives the GL4 binary API to GLES2.
Lastly, the divergence between GLES2 and GL3/4 core profile is a stinker as the intersection of the API’s are not compatible with each other (vertex array objects in particular along with 1 and 2 channel textures).
There are many times that I really, really freaking hate GLES2 in that it cut out so much functionality that is useful: flexible buffer mapping, almost all read back (buffer objects and textures), severe limitation on FBOs, control over active mipmap levels (this is restored via an extension though) and more if I keep thinking on it