Bug 53696

Created attachment 65756 [details]
Dante ( OpenGL ES )

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:
EGL_RENDERABLE_TYPE attribute equals EGL_OPENGL_BIT instead of EGL_OPENGL_ES2_BIT.

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.

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.

Kenney,

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:
  glGetString(GL_VERSION)
  glGetString(GL_EXTENSIONS)

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.

Kenney,

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