Bug 72600 - ES3 context returned when ES2 is requested
Summary: ES3 context returned when ES2 is requested
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: 9.2
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: mesa-dev
QA Contact:
Depends on:
Reported: 2013-12-11 15:45 UTC by org.freedesktop
Modified: 2018-03-01 10:43 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Description org.freedesktop 2013-12-11 15:45:58 UTC
As discussed on the mailing list:

> We've noticed that when an ES2 context is requested (on Mesa 9.2.4 and
> possibly earlier), an ES3 context is returned. ES3 obviously isn't
> strictly compatible with ES2 (for example, any code that uses
> glDrawElements with a pointer-to-array argument as opposed to a
> a VBO and buffer offset will fail, as ES3 doesn't support this).

The original issue as filed in the JOGL tracker:

Comment 1 org.freedesktop 2013-12-11 15:50:45 UTC
To clarify, the actual bug appears to be that the ES3 type bit is not set in
the EGL config (so the actual ES3 context doesn't correctly identify itself as
Comment 2 org.freedesktop 2013-12-11 15:51:32 UTC
Specifically EGL_OPENGL_ES3_BIT_KHR.
Comment 3 org.freedesktop 2013-12-11 16:01:04 UTC


It appears that this does happen on Mesa/Intel, but not on Mesa/AMD.
Comment 4 Kenneth Graunke 2013-12-11 21:16:36 UTC
ES3 is supposed to be backwards compatible with ES2, so silently promoting people from ES2 -> ES3 should be allowed.

It's like requesting a GL 2.1 context and getting promoted to a GL 3.0 or 4.3/compatibility context.

Is this actually a problem?9
Comment 5 Tapani Pälli 2013-12-12 05:27:01 UTC
IMO not a problem, I've been running my own gles2 engine + some of other gles2 benchmarks and none of them have any functional failures with current Mesa.
Comment 6 org.freedesktop 2013-12-12 18:06:05 UTC
I think the main issue here is that the ES3 context doesn't actually correctly
identify itself as such. As described in the JOGL tracker, the problem is that
JOGL first requests an ES2 context (and rejects the ES3 context that is actually
returned, more on that in a moment), and then tries an ES3 context but rejects
that because it doesn't have the correct type bits set.

As for rejecting an ES3 context when an ES2 context is requested, that's actually
rooted in:


As you can see from my comments at the bottom of 852, I'm not convinced that
ES3 and ES2 are incompatible either (my original statement made on the mailing
list appears to be in error).

As I said, evidently the context returned by Mesa on Intel drivers *does*
correctly identify itself as ES3, so there appears to be an (albeit minor) bug
on the AMD side.
Comment 7 org.freedesktop 2013-12-12 18:07:27 UTC
Probably worth changing the title of this bug if it does turn out that ES3 and
ES2 are fully compatible, and if it's actually possible to change bug titles...
Comment 8 Marek Olšák 2013-12-12 18:32:47 UTC
Did you build Mesa with --enable-gallium-egl? If yes, please turn it off and try again.
Comment 9 org.freedesktop 2013-12-12 18:51:20 UTC
It actually came from an OS package with these options (no patches are applied
to Mesa):


So yes, gallium EGL is enabled. I'll try building from source now.
Comment 10 Ian Romanick 2013-12-13 20:59:26 UTC
OpenGL ES 3.0 is intended to be almost completely backwards compatible with OpenGL ES 2.0.  The only known incompatibilities are cubemap filtering (ES3 requires seamless filtering, but ES2 requires non-seamless) and whether or not FBOs are shared.

If you discover what you believe to be an incompatibility, please report it to Khronos as it represents a bug in the specification.

For the record, user-arrays (i.e., vertex data that is not stored in a VBO) is still allowed in OpenGL ES 3.0.
Comment 11 org.freedesktop 2013-12-13 21:13:14 UTC
Yes, those are the conclusions I came to as well.

The only issue here, then, is the minor irritation of the ES3 context not setting
EGL_OPENGL_ES3_BIT_KHR. I think that's a conformance issue but I doubt anyone's
going to notice unless they're specifically validating contexts like that.
Comment 12 Jordan Justen 2013-12-13 21:49:09 UTC
(In reply to comment #11)
> The only issue here, then, is the minor irritation of
> the ES3 context not setting EGL_OPENGL_ES3_BIT_KHR.
> I think that's a conformance issue but I doubt anyone's
> going to notice unless they're specifically validating
> contexts like that.

Is a piglit test needed then?
Comment 13 Tapani Pälli 2018-03-01 10:43:51 UTC
I'm resolving this old bug as WORKSFORME. Mesa sets EGL_RENDERABLE_TYPE which can be queried via eglGetConfigAttrib and for ES3 compatible config it has EGL_OPENGL_ES3_BIT set. Please reopen if there is a bug.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.