Announcement

Collapse
No announcement yet.

OpenGL ES 3.0 Will Be Here This Summer

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Interesting...

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

    Comment


    • #17
      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...

      Comment


      • #18
        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.

        Comment


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

          Comment


          • #20
            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...

            Comment


            • #21
              Originally posted by Jedibeeftrix View Post
              Based on OpenGL 3.2+ rather than 3.3, i wonder if this answers why beyond3D people are saying that DX10 style geometry shaders are not part of the spec (added to OpenGL in 3.3 i believe)?

              Why would they cut that feature out? over and above more complex shader operations, geometry shaders were one of the key functionality advancements that DX10 added over the old 9.x series......
              The only reason for the existence of geometry shaders is that high-end desktop GPUs were getting so fast that a single-core CPU and PCIe 1.0 bus couldn't feed it small geometry fast enough. So instead some of the geometry can be generated on the GPU itself using a geometry shader.

              This is a pretty useless feature on an API for embedded systems because their GPUs are not very good at handling high polygon counts, and because in relative terms the CPU and the bus to the GPU is very fast.

              Comment


              • #22
                Soooo... I'm gleaning from this discussion that once the latest OpenGL ES is equal to the latest OpenGL, then OpenGL ES will be superior for desktop Linux as well as mobile. Also, it would allow OpenGL to finally surpass or meet DirectX in performance and power consumption. I'm guessing that it would also make developing the open source graphics drivers easier because they will not have to spend so much time worrying about backwords compatibility.

                Is this correct?

                Comment


                • #23
                  No, it is similar to 3.2 with some features missing.

                  The OpenGL performance with nVidia is already on par with Direct3D, draw-calls are even a little bit faster. As I mentioned earlier, the OpenGL specifications can benefit from adopting some nVidia extensions such as bindless graphics, which theoretically can boost VBO performance up to 7.5x, which might improve the real world performance 50-100% on heavy VBO workloads.

                  Comment


                  • #24
                    So once we reach a point when, let's say OpenGL ES 6 has the features of OpenGL 6, it will still be missing certain features? Even if that were the case, couldn't a new OpenGL PC, (which would essentially be OpenGL ES, but with the missing features added back in) replace standard OpenGL in order to overcome OpenGL's shortcomings? In case you cannot tell, I'm referring to the shortcomings pointed out by people who say that we need to replace OpenGL with something better, LibreGL for instance, lol.

                    Comment


                    • #25
                      Originally posted by Prescience500 View Post
                      So once we reach a point when, let's say OpenGL ES 6 has the features of OpenGL 6, it will still be missing certain features? Even if that were the case, couldn't a new OpenGL PC, (which would essentially be OpenGL ES, but with the missing features added back in) replace standard OpenGL in order to overcome OpenGL's shortcomings? In case you cannot tell, I'm referring to the shortcomings pointed out by people who say that we need to replace OpenGL with something better, LibreGL for instance, lol.
                      No. Because the OpenGL API is busted at the very core of its API design.

                      You cannot incrementally fix it. You need to toss it out and start over again. Gallium3D makes this relatively easy for the community to pull off, I might note. *nudge*

                      Comment


                      • #26
                        Originally posted by elanthis View Post
                        No. Because the OpenGL API is busted at the very core of its API design.

                        You cannot incrementally fix it. You need to toss it out and start over again. Gallium3D makes this relatively easy for the community to pull off, I might note. *nudge*
                        That I knew about OpenGL. I was under the impression that OpenGL ES was made almost form scratch though to be better optimized. I guess, from what you said, that's not the case though.

                        Comment


                        • #27
                          Originally posted by elanthis View Post
                          No. Because the OpenGL API is busted at the very core of its API design.

                          You cannot incrementally fix it. You need to toss it out and start over again. Gallium3D makes this relatively easy for the community to pull off, I might note. *nudge*
                          How is the OpenGL API supposedly busted? (and why is Direct3D not?)

                          Gallium3D adds another abstraction level with overhead and feature limitations. The API(OpenGL/Direct3D) is supposed to be the abstraction between hardware and the application, adding another level is just simply stupid.

                          Comment


                          • #28
                            Originally posted by efikkan View Post
                            How is the OpenGL API supposedly busted? (and why is Direct3D not?)

                            Gallium3D adds another abstraction level with overhead and feature limitations. The API(OpenGL/Direct3D) is supposed to be the abstraction between hardware and the application, adding another level is just simply stupid.
                            IIRC, elanthis mentioned several times the limitations of OpenGL (being a state machine) concerning proper multithreading.

                            Comment


                            • #29
                              Originally posted by efikkan View Post
                              How is the OpenGL API supposedly busted? (and why is Direct3D not?)

                              Gallium3D adds another abstraction level with overhead and feature limitations. The API(OpenGL/Direct3D) is supposed to be the abstraction between hardware and the application, adding another level is just simply stupid.
                              And who is going to write the abstraction for each driver? You?

                              Gallium is just common/helper stuff shared by drivers, like OpenGL state tracker and resource management. It won't be as fast as a custom-tailored implementation. But it is not like there are 200+ developers to work on one in the first place.

                              Comment


                              • #30
                                Originally posted by efikkan View Post
                                How is the OpenGL API supposedly busted? (and why is Direct3D not?)

                                Gallium3D adds another abstraction level with overhead and feature limitations. The API(OpenGL/Direct3D) is supposed to be the abstraction between hardware and the application, adding another level is just simply stupid.
                                Elanthis has mentioned before he wants a more object-oriented API. Think C++ instead of C.

                                I agree that Gallium doesn't really do anything here, though - maybe it's a quick way to prototype changes, but ultimately nothing is ever going to get adopted unless NVidia and AMD bye in, and they've shown pretty conclusively I think that they aren't willing to change GL radically. I don't see how the chances of them adopting a completely new replacement could possibly be any better.

                                Comment

                                Working...
                                X