jakogut jakogut - 3 months ago 9x
Android Question

Why do many mobile GPUs support OpenGL ES, but not OpenGL?

For instance, out of the entire ARM Mali line, many GPUs support OpenGL ES 3+, Direct3D 9+ (some support up to 11/12), and some support Vulkan, but none support OpenGL, not even newer versions of OpenGL that deprecated the fixed pipeline. Same thing with Adreno.

Is the hardware incapable of supporting full GL (if so, why?), or did the driver developers just not implement it?


Because OpenGL ES was created exactly to target "embedded" hardware.

On the other hand, the idea of creating OpenGL ES as a separate standard instead of being just a "subset" of OpenGL (today we would call it a "profile", if you want) was a very, very, very, very, very, very, very, very, very bad idea.

The major implication that you're facing here is that, in order to implement OpenGL support in addition to OpenGL ES, vendors would need to develop another similar but subtly different GL library. And that means extra development effort, testing, certification. So, for them, it's far easier to push this effort onto developers and ask them to create different renderers, targeting OpenGL on desktop and OpenGL ES on embedded.

(Luckily, if you have OpenGL, this mess is somehow "simplified" by the GL_ARB_ESx_compatibility extensions, that allow you to have some OpenGL ES datatypes / calls / features, so you're able to re-use more code.)

Apart from this, you're right -- if the hardware supports Vulkan, then it would support OpenGL 4.5 / DX12. Roughly speaking, each of this line targets a different hardware generation:

  • OpenGL 2.1 (+ FBOs) | OpenGL ES 2 | Direct3D 9
  • OpenGL 3.3 | OpenGL ES 3.0/3.1 | Direct3D 10
  • OpenGL 4 | OpenGL ES 3.2 | Direct3D 11

Plus a line which would look like "OpenGL 4.5 | Vulkan | Direct3D 12".

(Yes, the OpenGL ES version numbers don't even make sense and don't match the OpenGL ones, I assume so that vendors are not scared by having to jump a major number and instead see them as "incremental" changes, although ES 3.2 requires way more silicon than 3.0)

In practice the devil is in the details, so you've got f.i. tessellation in OpenGL ES 3.2 but in OpenGL 4.0, but compute shaders were already in OpenGL ES 3.1 but in OpenGL got introduced later -- 4.3 --, and other levels of such crazyness.