Going From OpenGL ES To OpenGL Over EGL Is Easy

[phoronix]

Phoronix: Going From OpenGL ES To OpenGL Over EGL Is Easy

Going from supporting to OpenGL ES to OpenGL while using EGL rather than GLX is quite easy, as shown by recent work on the open-source Doom 3 code-base...

http://www.phoronix.com/vr.php?view=MTE2NDM

[mark45]

While being good news, the article itself is sloppy and, as usually, not once being read by the author himself, the very first line reads: "Going from supporting to OpenGL ES to OpenGL.."

The source code, according to Pekka, is also rather crude and in alpha state.

[dh04000]

I have a nongrammar nazi question here. Would it be possible to create a stand along library that allows developers to write a engine in opengl or opengl ES and have the program be run in either?

Kinda like how the opendoom3 people are suggesting? But in a stand alone way that could work with any application using opengl or opengl ES?

[plonoma]

@dh04000

OpenGL ES (at least with 3.0) is a subset of OpenGL (ES3.0 -> 4.3). With sticking to the subset it should be possible to have something that can run on either. Most modern OpenGL drivers can also create an OpenGL ES context. Thus a program written with only OpenGL ES can run kinda everywhere.

[Dandel]

Phoronix: Going From OpenGL ES To OpenGL Over EGL Is Easy
[... SNIP until end of article]
While it's easy on the application/game side, there's still EGL/OpenGL bugs within Mesa to be ironed out -- i.e. this new bug for exposing OpenGL extensions rather than OpenGL ES extensions when using EGL.

This bug report is Partially caused by the lack of Samples... The only driver that implements OpenGL W/ EGL contexts is Mesa... so pretty much right now all other drivers must match this.

Anyways, This is "Expected" behaviour the EGL 1.4 specification clearly states what the default rendering API is. Just read Section 3.7.1. This section clearly states that the default setting is OpenGL ES ( EGL_OPENGL_API ) when OpenGL ES support is within the driver. However, when OpenGL ES support is not available the default rendering API is set to Nothing ( EGL_NONE ). This means that if the egl driver binds to opengl by default when opengl es is not supported, It's not following spec.

[Pickle]

Not sure exactly why this news, i guess it just another reason to say doom3....this just in Khronos released a spec years ago that defined EGL_OPENGL_API!!!!!

If a developer sticks to the right API they can run in any version of OpenGL needed with few compile time modifications.

I have to give some thanks to mesa/intel for providing support for ES 1.X/ES 2.0/Full OpenGL. Its great to be able to develop and test out any GL version of the render on the same machine (and a desktop at that). I added a ES 2.0 render to one of projects and I was able to test out builds for 1.X ES, 2.0 ES, OpenGL 1.5+, OpenGL 2.0+.

Personally I use SDL to establish the OpenGL context for desktop targets. For linux it has the benefit of being able to use the rest of the SDL subsystems like input and sound. The other benefit is that the same code will work on windows (mayb mac never tested). The SDL code with some minor glue code can even be used with EGL. SO it basically comes down to one code path for all systems.

[nadro]

The only driver that implements OpenGL W/ EGL contexts is Mesa... so pretty much right now all other drivers must match this.

AMD binary drivers also support EGL context

[smitty3268]

I have a nongrammar nazi question here. Would it be possible to create a stand along library that allows developers to write a engine in opengl or opengl ES and have the program be run in either?

Kinda like how the opendoom3 people are suggesting? But in a stand alone way that could work with any application using opengl or opengl ES?

Someone is writing a small library for piglit (the mesa test library) so that it can choose whether to run GL/GLX or GL ES/EGL at runtime.

I can't remember what it was called though.