Announcement

Collapse
No announcement yet.

The Many Problems With OpenGL

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

  • The Many Problems With OpenGL

    Phoronix: The Many Problems With OpenGL

    Rich Geldreich of Valve has written a opinion piece on the gripes he has with OpenGL...

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

  • #2
    I haven't worked with OpenGL all that much, but while the attitude of "throw legacy away" makes sense in a way, on the other hand it makes me think it might overcomplicate things... My card game uses OpenGL 2 commands, instead of shaders, because I literally need only textured squares. Doing the same thing with shaders would be more complicated than just calling functions that do it. And yet the function pipeline is considered legacy.
    Of course, that could be solved by making a library in which those functions create shaders and whatnot, but at the moment I'm not aware of such libraries...

    Comment


    • #3
      Twenty years sounds a bit over the top for me.

      I do not think many people use 20 year old hardware, and even if they do, they could use an older version of openGL.

      Or am I thinking to simple ?

      Comment


      • #4
        microsoft advantage at least on XP, is that microsoft engineering makes simple and flexible what linux makes complex and rigid.

        "Be water my friend": Bruce Lee.

        couldn't hardware MAP ITSLEF!?
        Last edited by Azrael5; 05-12-2014, 10:20 AM.

        Comment


        • #5
          Originally posted by GreatEmerald View Post
          I haven't worked with OpenGL all that much, but while the attitude of "throw legacy away" makes sense in a way, on the other hand it makes me think it might overcomplicate things... My card game uses OpenGL 2 commands, instead of shaders, because I literally need only textured squares. Doing the same thing with shaders would be more complicated than just calling functions that do it. And yet the function pipeline is considered legacy.
          Of course, that could be solved by making a library in which those functions create shaders and whatnot, but at the moment I'm not aware of such libraries...
          If you only need textured squares, why are you using OpenGL at all? Couldn't this easily be achieved without a GL API on any even slightly modern hardware? My programming experience is limited, but I've at least made basic colored and textures shapes in my limited experience with C/C++. Wouldn't that leave OpenGL for more high performance 3D applications, then?

          Comment


          • #6
            Originally posted by Gps4l View Post
            Twenty years sounds a bit over the top for me.

            I do not think many people use 20 year old hardware, and even if they do, they could use an older version of openGL.

            Or am I thinking to simple ?
            I think that's the point, modern OpenGL still has support for that old hardware. And by "support", I mean a lot of legacy cruft in the codebase, not that it'll actually run on that old hardware. Rich wants to dump said cruft in favour of a modern, simpler API. Remove all the old, "legacy" stuff, the "compatibility" modes and so on to create a leaner, simpler API.

            Comment


            • #7
              Sad, but true

              Having to deal with some of those issues, I must admit he is right.
              What would be interesting now, is to know what is the action plan from Khronos board members to overcome this with the next openGL API.
              Making a global simplification, and having a bindless API will be the minimum requirements to compete with D3D12 and Mantle in 2015.

              Comment


              • #8
                Originally posted by dffx View Post
                If you only need textured squares, why are you using OpenGL at all? Couldn't this easily be achieved without a GL API on any even slightly modern hardware? My programming experience is limited, but I've at least made basic colored and textures shapes in my limited experience with C/C++. Wouldn't that leave OpenGL for more high performance 3D applications, then?
                Or just use SDL2 or some other OpenGL accelerated 2D library? On another hand, rewriting your program to use shaders instead of fixed pipeline would probably take you a handful of hours, since the shaders you need are extremely rudimentary.

                I recommend Tom Dalling's tutorials: http://tomdalling.com/blog/category/modern-opengl/

                There you'll get the simple shaders you need for texturing and lighting.

                Comment


                • #9
                  Are Geldreich and elanthis the same person?

                  Comment


                  • #10
                    I agree with much of that, but the only elephant in the room is Khronos' lack of certification. It's pretty much the only thing that could give Intel's Windows and AMD's Catalyst teams a much-needed kick in the ass.

                    As much as a single crash or misworking API when running heavy multithreaded torture tests? No cert for you.

                    Comment


                    • #11
                      skimmed through his blog post... very pointed complaints- maybe it's time for Khronos to create a brand new/simpler API, not necessarily backward compatible at the API level with all the legacy crap he's alluding to, but functionally compatible yet simpler API that hopefully draws game programmers to it (and hopefully puts more nails in DirectX's coffin) for new development.... and hopefully porting of engines to this new API.

                      Comment


                      • #12
                        Originally posted by phoronix View Post
                        Phoronix: The Many Problems With OpenGL

                        Rich Geldreich of Valve has written a opinion piece on the gripes he has with OpenGL...
                        He should have commented on OpenGL ES which supposedly resolves a lot of the legacy issues he refers to.

                        Comment


                        • #13
                          Originally posted by DanLamb View Post
                          He should have commented on OpenGL ES which supposedly resolves a lot of the legacy issues he refers to.
                          Isn't GL ES only for embedded tho? (not a GL programmer here).

                          Comment


                          • #14
                            With OpenGL beeing the only API on linux, I wonder how much politics is working in the background to sabotage it?! (And now a totaly unrelated HELLO to M$ in the Khronos board!)
                            Ignoring GLES and the mobile stuff. The two big vendors that really matter in the performance arena are Nvidia and AMD. Both for example support DSA that was first drafted in the end of 2007. But still there are no known plans to make it core!

                            Sure there is a need for a legacy OpenGL support. But that can be put into a user space library that uses a decent graphic API as backbone. There is no excuse to not ditch the legacy clutter already.

                            Originally posted by GreatEmerald View Post
                            I haven't worked with OpenGL all that much, but while the attitude of "throw legacy away" makes sense in a way, on the other hand it makes me think it might overcomplicate things... My card game uses OpenGL 2 commands, instead of shaders, because I literally need only textured squares. Doing the same thing with shaders would be more complicated than just calling functions that do it. And yet the function pipeline is considered legacy.
                            Of course, that could be solved by making a library in which those functions create shaders and whatnot, but at the moment I'm not aware of such libraries...
                            The Hardware API is not supposed to micro manage that much for you. For that you use/make user space librarys like the already mentioned 2D functions from SDL2.
                            And user space librarays would be way easyer to develop for an API that is not bloated by 20 years of accumulated design changes.

                            Except for very small programs you write your own layer betwin your program and the graphic api. Thats why DSA (and it NOT beeing part of core) matters so much.

                            Comment


                            • #15
                              Originally posted by MartinN View Post
                              Isn't GL ES only for embedded tho? (not a GL programmer here).
                              If you can run full GL 4.3, you can run GLES 3.0 on it without rewriting anything, it has the GLES link table. I think version 4.1 or something matched GLES 2. Which means you could write GLES 3.0 code, and have it run on all Android devices, and any GL 4.3 driver, without rewrites.

                              The problem is that even GLES has legacy stupidity in it. It didn't start out as a programmable pipe, so they made the same mistake twice and it wasn't until ES 2.0 that the shader language was added. So once again, you have all the GLES 1.X legacy crap nobody will use on a programamble chip but you gotta carry it along for the ride.

                              It isn't as bad as the mess of pre GL 3 nonsense, though. I'd definitely write a game to GLES3, just so that it has portability on everything, even if everything isn't necessarily modern - by the time any project I'd start today was ready, it would take two years, so you could expect GL 4.3+ and ES 3.0+ on all major platforms and on a huge percentage of peoples devices.

                              Comment

                              Working...
                              X