According to the spec, GL_VERSION should report the GLES version supported by the current context. However, it appears that PVRVFrame is reporting some other GLES version (e.g. max possible GLES version?).
I checked this behavior in PVRVFrame for SDK 3.5 and 4.0. In SDK 4.0, the GL_VERSION format did get fixed, but its version still doesn’t track the context version.
In the example tested, I forced a GLES 2.0 context, then queried GL_VERSION. SDK 4.0’s PVRVFrame reports:
“OpenGL ES 3.0 (Host : 4.5.13411 Core Profile Context FireGL 15.201.2401.0)”
SDK 3.5’s PVRVFrame is similar, but looks like this:
“3.0(…)”
Reference:
https://www.khronos.org/registry/egl/extensions/KHR/EGL_KHR_create_context.txt
[blockquote] Querying the GL_VERSION string with glGetString in either OpenGL or
OpenGL ES [or the GL_MAJOR_VERSION and GL_MINOR_VERSION values with
glGetIntegerv, in an OpenGL 3.0 or later context] will return the
actual version supported by a context.[/blockquote]
Hi Dark_Photon
How are you attempting to force a GLES 2.0 context? The way to do it is to filter the list of configs returned by eglGetConfigs to find a config whose EGL_RENDERABLE_TYPE bitmask does not have the EGL_OPENGL_ES3_BIT_KHR flag set. Requesting a version via eglCreateContext isn’t enough because implementations are free to return any context which is compatible or backwards-compatible with the requested version (see section 3.7.1.1 of the EGL spec https://www.khronos.org/registry/egl/specs/eglspec.1.5.pdf). Don’t shoot the messenger! 
Thanks chris! Apologies if the bug is really on my side. I did dig in the spec first, but could have missed something.
I tell you the scenario we hit this in: with PVRVFrame/PVRTrace from SDK 3.5, using an EGLconfig with both ES2_BIT and ES3_BIT set, we try to create an eglContext with EGL_CONTEXT_CLIENT_VERSION == 3. If that fails, we drop back and submit a context create for EGL_CONTEXT_CLIENT_VERSION == 2.
Normally, the ES3 context creation succeeds. However, one one machine, the eglCreateContext for ES3 failed, returning EGL_NO_CONTEXT. So we fell back and successfully created an ES2 context.
Though that is what is happening, I think there may still be a bug in how we are creating contexts (though it didn’t affect us here because the EglConfig obtained supported both ES3 and ES2. That is, we are not insisting that the EglConfig has the appropriate bit set before trying to use it to create a context with a specific EGL version. Will fix that. But like I said, that didn’t affect us here.
Thanks for your help!
Hi chris,
Quick follow-up question related to our GL_VERSION discussion.
In this case where we:
[ol][li]Obtain an eglConfig which supports both ES2 and ES3,[/li]
[li]Try to create an ES3 EGL context with it, which fails (EGL_NO_CONTEXT),[/li]
[li]Try to create an ES2 EGL context with it, which succeeds,[/li]
[li]And this context returns a GL_VERSION for OpenGL ES “3.0”,[/li][/ol]
Do we assume that this context supports ES3 capabilities? Or only ES2? I think that’s the root of my confusion.
Ah I am surprised to hear that is happening, it’s definitely a bug. I’ve identified the situation where it might happen.
Short answer is “yes”. With PVRVFrame You can always trust GL_VERSION to properly report the capabilities of the context.
Long answer - PVRVFrame has a “strict context creation” mode, toggleable from the PVRVFrameGUI -> Preferences window. When this is enabled eglCreateContext will check for the presence of GL_ARB_ES2_compatibility or GL_ARB_ES3_compatibility depending on the context version requested, and fail with EGL_BAD_ALLOC if the extension is not present. Switching to “loose” mode in this situation should allow eglCreateContext to succeed.
The bug here is, when an ES2 context is requested, eglCreateContext is checking for ES2_compatibility, which succeeds, and then elevating the context version to ES3 and returning an unchecked ES3 context.
In hindsight, checking for the presence of ES2/ES3 capabilities by checking for these ARB extensions isn’t a perfect solution since graphics cards are typically lax about reporting their presence even when they are supported. We were hoping to fix this for the 4.0 release but unfortunately time didn’t allow.
Hope this is clear!
Thanks you Chris! I appreciate you looking into this, and yes, it makes sense.
