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
such).

Specifically EGL_OPENGL_ES3_BIT_KHR.

Additional:

EGL_RENDERABLE_TYPE shall have bit EGL_OPENGL_ES3_BIT_KHR set.

It appears that this does happen on Mesa/Intel, but not on Mesa/AMD.

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

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.

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:

  https://jogamp.org/bugzilla/show_bug.cgi?id=852

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.

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...

Did you build Mesa with --enable-gallium-egl? If yes, please turn it off and try again.

It actually came from an OS package with these options (no patches are applied
to Mesa):

  https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/mesa

So yes, gallium EGL is enabled. I'll try building from source now.

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.

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.

(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?

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.