Results 1 to 8 of 8

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

  1. #1
    Join Date
    Jan 2007
    Posts
    15,429

    Default Going From OpenGL ES To OpenGL Over EGL Is Easy

    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

  2. #2
    Join Date
    May 2012
    Posts
    912

    Default

    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.

  3. #3
    Join Date
    Aug 2012
    Posts
    510

    Default

    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?

  4. #4
    Join Date
    Sep 2010
    Posts
    486

    Default

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

  5. #5
    Join Date
    Oct 2007
    Posts
    321

    Default

    Quote Originally Posted by phoronix View Post
    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.

  6. #6
    Join Date
    Jun 2008
    Posts
    75

    Default

    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.

  7. #7
    Join Date
    Jan 2008
    Posts
    114

    Default

    Quote Originally Posted by Dandel View Post
    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

  8. #8
    Join Date
    Oct 2008
    Posts
    3,219

    Default

    Quote Originally Posted by dh04000 View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •