Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 34

Thread: OpenGL ES 3.0 Will Be Here This Summer

  1. #11
    Join Date
    Dec 2011
    Posts
    2,159

    Default

    Quote Originally Posted by BlackStar View Post
    OpenGL ES is a much smaller API in terms of entry points (functions) and functionality. OpenGL ES 2.0 is based on OpenGL 2.1 but with all legacy functions removed (i.e. no immediate mode rendering, no display lists, no fixed-function functionality.) OpenGL ES 3.0 will bring newer functionality equivalent to OpenGL 3.x (FBOs by default, more flexible shaders), with the possible exception of geometry shaders (which are much less useful than they sound, esp. in the mobile space.)

    Apart from these differences, there are OpenGL ES versions for devices without floating-point hardware and for devices with increased stability requirements.

    In short, OpenGL ES is closer to what OpenGL could have been if it wasn't burdened by backwards compatibility.
    So they're pretty much same powerful and flexible?
    OpenGL ES is easier to learn and develop with?

  2. #12
    Join Date
    Nov 2007
    Posts
    1,024

    Default

    Quote Originally Posted by uid313 View Post
    So they're pretty much same powerful and flexible?
    OpenGL ES is easier to learn and develop with?
    Core profile OpenGL is also cleaned up and refined more or less identically to OpenGL ES. The API was fully aligned between OpenGL ES 2.0 and OpenGL 4.2, and will likely be aligned between OpenGL ES 3.0 and OpenGL 4.3 (if not 4.2). Desktop OpenGL has a ton of features and support than OpenGL ES does not. The rumors for OpenGL ES 3 would make it almost -- but not quite -- equivalent to D3D10. The direct comparison is a bit uneven (even today's GL ES devices have some features only found in D3D11, while D3D11 still has features that no version of GL offers even with extensions -- primarily threading support, which is basically impossible to do properly with the 1980's single-threaded GL/GLES API design).

    So far as "easier to learn," the old deprecated OpenGL API is actually much "easier," which is why it's stuck around so long and why hobbyists and students keep clinging to it despite how awful it is for performance. Of course it's trivial to build such an easy API on top of GL3 or D3D, but nobody has written one (at least none that is widely known and ubiquitous). D3D10+ is also considered easier to learn and develop with compared to any version of GL ES or Core profile GL (again due to GL/GLES having that ancient 1980's style API, which is difficult to thread properly due to global state, is highly error prone and difficult to debug, is unfriendly to code completion, etc.).

  3. #13
    Join Date
    May 2012
    Posts
    912

    Default

    OpenGL ES 2.0 (GLES2) requires EGL to setup and run, or the use of special nvidia/amd extensions for the desktop (which I don't know how to use) to setup and run GLES2.

    More importantly, GLES2 is designed to run without GLX (which is why it typically requires the platform-neutral EGL), which allows it to run on mobiles and other systems which don't need X.org or can't run it, that's why Wayland requires (and defines its own) EGL - because Wayland needs to run independently without having to depend on GLX (X.org).

    Thus as a desktop dev it's better to target GL 3.3 unless you're after WebGL or mobiles.
    Last edited by mark45; 05-27-2012 at 11:45 PM.

  4. #14
    Join Date
    Jun 2011
    Location
    Barcelona
    Posts
    74

    Default

    Quote Originally Posted by mark45 View Post
    OpenGL ES 2.0 (GLES2) requires EGL to setup and run, or the use of special nvidia/amd extensions for the desktop (which I don't know how to use) to setup and run GLES2.

    More importantly, GLES2 is designed to run without GLX (which is why it typically requires the platform-neutral EGL), which allows it to run on mobiles and other systems which don't need X.org or can't run it, that's why Wayland requires (and defines its own) EGL - because Wayland needs to run independently without having to depend on GLX (X.org).

    Thus as a desktop dev it's better to target GL 3.3 unless you're after WebGL or mobiles.
    I don't really get what you mean.

  5. #15

    Default

    Quote Originally Posted by mark45 View Post
    OpenGL ES 2.0 (GLES2) requires EGL to setup and run, or the use of special nvidia/amd extensions for the desktop (which I don't know how to use) to setup and run GLES2.
    http://www.g-truc.net/post-0457.html

  6. #16
    Join Date
    Jul 2011
    Posts
    59

    Question Interesting...

    Quote Originally Posted by elanthis View Post
    Core profile OpenGL is also cleaned up and refined more or less identically to OpenGL ES. The API was fully aligned between OpenGL ES 2.0 and OpenGL 4.2, and will likely be aligned between OpenGL ES 3.0 and OpenGL 4.3 (if not 4.2). Desktop OpenGL has a ton of features and support than OpenGL ES does not. The rumors for OpenGL ES 3 would make it almost -- but not quite -- equivalent to D3D10. The direct comparison is a bit uneven (even today's GL ES devices have some features only found in D3D11, while D3D11 still has features that no version of GL offers even with extensions -- primarily threading support, which is basically impossible to do properly with the 1980's single-threaded GL/GLES API design).

    So far as "easier to learn," the old deprecated OpenGL API is actually much "easier," which is why it's stuck around so long and why hobbyists and students keep clinging to it despite how awful it is for performance. Of course it's trivial to build such an easy API on top of GL3 or D3D, but nobody has written one (at least none that is widely known and ubiquitous). D3D10+ is also considered easier to learn and develop with compared to any version of GL ES or Core profile GL (again due to GL/GLES having that ancient 1980's style API, which is difficult to thread properly due to global state, is highly error prone and difficult to debug, is unfriendly to code completion, etc.).
    http://www.opengl.org/wiki/OpenGL_and_multithreading

    Apparently, elanthis isn't the all-knowing "low-level graphics driver API god" he always pretends to be...

  7. #17
    Join Date
    Jun 2010
    Location
    ฿ 16LDJ6Hrd1oN3nCoFL7BypHSEYL84ca1JR
    Posts
    1,052

    Default

    Quote Originally Posted by elanthis View Post
    So far as "easier to learn," the old deprecated OpenGL API is actually much "easier," which is why it's stuck around so long and why hobbyists and students keep clinging to it despite how awful it is for performance.
    You have said this before but is it really that big?

    I mean, for engines that can render to direct3d and opengl like unigine at least the unigine heaven benchmark doesn't have a big performance difference, does it?

    And even wine, where direct3d is automatically translated to opengl and I imagine there is not much room for individual optimization for opengl the performance seems to be good enaugh...

  8. #18
    Join Date
    Jan 2007
    Posts
    11

    Default

    Quote Originally Posted by ChrisXY View Post
    You have said this before but is it really that big?

    I mean, for engines that can render to direct3d and opengl like unigine at least the unigine heaven benchmark doesn't have a big performance difference, does it?

    And even wine, where direct3d is automatically translated to opengl and I imagine there is not much room for individual optimization for opengl the performance seems to be good enaugh...
    I believe that the performance penalty being talked about is between the old style, deprecated GL apis and the newer GL rather than between GL and DX.

    For example, using 'old style' glVertex calls means that every frame, every vertex has to be copied to the graphics card over a (relatively slow) bus, while 'newer style' GL (e.g. VBOs) allows all the vertices to be copied once, then re-used per frame. This will obviously have a performance impact.

    I believe that DX10+ also required use of similar functions to the newer opengl, and are both of similar functionality, so I would expect any performance difference to be based on optimizations of the driver or user app, rather than a fundamental difference between the APIs.

  9. #19
    Join Date
    Jun 2010
    Location
    ฿ 16LDJ6Hrd1oN3nCoFL7BypHSEYL84ca1JR
    Posts
    1,052

    Default

    Ah ok, I didn't read that right. Disregard it then.

  10. #20
    Join Date
    Nov 2008
    Posts
    77

    Default

    I had always thought that OpenGL 3.1 Core Profile was the intended successor for OpenGL ES 2.0, but obviously I was wrong.

    On the other hand, it looks like OpenGL ES 3.0 will be a superset of OpenGL 3.1 Core Profile (though not of the 3.2 or 3.3 core profiles), so I wasn't that far off...

Posting Permissions

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