Bug 53696 - EGL: GL contexts show GLES extensions
Summary: EGL: GL contexts show GLES extensions
Alias: None
Product: Mesa
Classification: Unclassified
Component: Other (show other bugs)
Version: 8.0
Hardware: x86-64 (AMD64) Linux (All)
: medium blocker
Assignee: Chad Versace
QA Contact:
Depends on:
Reported: 2012-08-19 05:22 UTC by Kenney Phillis Jr
Modified: 2012-08-24 18:31 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

Default output ( using GLX Contexts ) (10.19 KB, text/plain)
2012-08-19 05:22 UTC, Kenney Phillis Jr
Dante ( OpenGL ES ) (7.08 KB, text/plain)
2012-08-19 05:23 UTC, Kenney Phillis Jr
Dante ( OpenGL + EGL ) (5.88 KB, text/plain)
2012-08-19 05:26 UTC, Kenney Phillis Jr
Dante ( OpenGL + EGL + eglBind ) (5.88 KB, text/plain)
2012-08-19 05:27 UTC, Kenney Phillis Jr
Small test program that has this issue. (6.96 KB, text/plain)
2012-08-21 01:30 UTC, Kenney Phillis Jr

Note You need to log in before you can comment on or make changes to this bug.
Description Kenney Phillis Jr 2012-08-19 05:22:22 UTC
Created attachment 65755 [details]
Default output ( using GLX Contexts )

While Attempting to see what i can do with OpenGL using the EGL contexts I found that the OpenGL ES client type seems to override the OpenGL settings. I created a context with the client attribute of EGL_RENDERABLE_TYPE set to EGL_OPENGL_BIT, however when I check all the details within the context it gives the OpenGL ES data instead. This is a little annoying since I know for certain that everything works under OpenGL directly ( using GLX ), but not with the newer context types ( namely EGL).

Anyways, The relevant source code tree can be found at github:


as for two specific files of interest, see:
and: https://github.com/kphillisjr/dante/blob/es2/neo/renderer/qgl.h

As for testing this, Doom 3 is required, however You can get away with the Doom 3 demo ( Although, I have no idea how to work with this ).

Anyways, I will not go into dependencies of the code, however libvorbis, libogg, openal, alsa-sound, xf86mode, opengl libs, egl libs, opengl es 2 libs are all part of the list of the requirements to build. However, There is also the requirement of python and scons to build... Also, if you do not wish to install the curl dev files, add "NOCURL=1" to the compile options.

# Build Doom 3 ( OpenGL ES ) Contexts
scons -j8

# Build Doom 3 (OpenGL Version) that uses GLX Contexts
scons TARGET_OPENGL=1 -j8

# Build Doom 3 (OpenGL Version) that uses GLX Contexts
Comment 1 Kenney Phillis Jr 2012-08-19 05:23:57 UTC
Created attachment 65756 [details]
Dante ( OpenGL ES )
Comment 2 Kenney Phillis Jr 2012-08-19 05:26:37 UTC
Created attachment 65757 [details]
Dante ( OpenGL + EGL )

For this log, I did not make any calls to eglBind after the context was created. However, This clearly shows that there is trouble brewing.

For this, all that is set differently is:
Comment 3 Kenney Phillis Jr 2012-08-19 05:27:40 UTC
Created attachment 65758 [details]
Dante ( OpenGL + EGL + eglBind )

This binds OpenGL after the context is created, however no change. the renderer still thinks it is OpenGL ES 1.x instead of OpenGL 2.x.
Comment 4 Pekka Paalanen 2012-08-20 07:27:37 UTC
Hi, a couple of things you could check, since from a quick glance of the code I could not spot them:

- where does your code call eglBindAPI() to take the big OpenGL into use? Or the ES API?

- where does your code set the context attribute EGL_CONTEXT_CLIENT_VERSION to 2 to get GLESv2 instead of GLESv1?

OpenGL ES is the default rendering api, so if you never call eglBindAPI, you will always get ES. If you don't define the context attribute, you will always get ES1 from ES1 vs. ES2.

EGL_RENDERABLE_TYPE does not choose which API you are currently using. It only chooses which APIs you could use to render with the config.
Comment 5 Chad Versace 2012-08-20 21:42:19 UTC

Occasionally, I run Mesa's testsuite, Piglit, under X11/EGL. And I have never encountered this probelm. So, to be convinced that this bug exists, we need an easily reproducible testcase.

Please write a small, standalone program that reproduces this problem. The program should just create an OpenGL context and print the following:
Comment 6 Kenney Phillis Jr 2012-08-21 01:30:47 UTC
Created attachment 65859 [details]
Small test program that has this issue.

Ok, I have a small program. Please Note that most of the code is for initialization, and that the primary issue is shown with the following...

line 35 - This line shows Ever intent of using an OpenGL Context, because the configuration was specifically requesting a configuration cable.

line 233 to 244 - This one line depending on whether or not it's called has this issue. 

Anyways, This might show a little bit more of the unspecified nature of using OpenGL with EGl... It's possible that the original code was completely wrong, however, from a programmers point of view, they are clearly showing every intention of using OpenGL.
Comment 7 Chad Versace 2012-08-24 18:31:38 UTC

(In reply to comment #6)
> Created attachment 65859 [details]
> Small test program that has this issue.
> Ok, I have a small program. Please Note that most of the code is for
> initialization, and that the primary issue is shown with the following...

Thanks for writing the program. Now it's clear that there is no bug.

Here is what's happening... eglChooseConfig returns a config in which the EGL_RENDERABLE_TYPE bitmask contains the bit that you requested: EGL_OPENGL_BIT. The bitmask additionally contains the EGL_OPENGL_ES_BIT; that is, eglGetConfigAttrib(EGL_RENDERABLE_TYPE) returns EGL_OPENGL_BIT | EGL_OPENGL_ES_BIT. The EGL implementation may legally do this.

When you call eglCreateContext with that config, the EGL implementation can create either a GL or GLES context because both bits are set in the EGL_RENDERABLE_TYPE bitmask. The chosen context API depends on the currently bound API, which is initially EGL_OPENGL_ES_API. From the EGL 1.4 spec:

"""The initial value of the current rendering API is EGL_OPENGL_ES_API, unless
OpenGL ES is not supported by an implementation, in which case the initial value
is EGL_NONE. Applications using multiple client APIs are responsible for ensur-
ing the current rendering API is correct before calling the functions eglCreate-
Context, [...]"""

In summary, according to the EGL spec you must call eglBindAPI(EGL_OPENGL_API) before attempting to create a GL context. Yeah, EGL is very clumsy and non-intuitive in this detail, but the spec is the spec.

bug/show.html.tmpl processed on Mar 27, 2017 at 16:30:17.
(provided by the Example extension).