Announcement

Collapse
No announcement yet.

Recapping The OpenGL 4.5 Improvements, NVIDIA Linux Changes

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

  • Recapping The OpenGL 4.5 Improvements, NVIDIA Linux Changes

    Phoronix: Recapping The OpenGL 4.5 Improvements, NVIDIA Linux Changes

    NVIDIA's Mark Kilgard presented at SIGGRAPH 2014 in Vancouver to cover the changes found in the just-released OpenGL 4.5 specification. He also went over some of NVIDIA's Linux driver changes...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Deslided presentation

    Link to deslided presentation

    Comment


    • #3
      Reading about Direct State Access makes me wonder why on earth was such thing not implemented in OpenGL 1? Why the hell was the non-DSA functions implemented in the first place?

      Comment


      • #4
        Originally posted by sarmad View Post
        Reading about Direct State Access makes me wonder why on earth was such thing not implemented in OpenGL 1? Why the hell was the non-DSA functions implemented in the first place?
        Perhaps it didn't make sense for OpenGL 1.0 at the time. Also, SGI was controlling the API. There wasn't even consumer hardware that could do OpenGL (or 3D).

        Comment


        • #5
          Talk replay available

          Originally posted by turol View Post
          A replay of the talk with audio and the live demos can be found here:

          http://www.ustream.tv/recorded/51255959

          Comment


          • #6
            Originally posted by marek View Post
            Perhaps it didn't make sense for OpenGL 1.0 at the time. Also, SGI was controlling the API. There wasn't even consumer hardware that could do OpenGL (or 3D).
            Actually back in the original OpenGL 1.0 days, there wasn't even the notion of texture objects. Instead there was only a current 1D and 2D texture target. The plan was that display lists could be used to "encapsulate" texture image state. That didn't work out very well and so texture objects were added in OpenGL 1.1 and the glBindTexture selector was introduced to minimize the API impact of supporting texture objects.

            The issue had nothing really to do with "SGI controlling the API". Even in OpenGL 1.0 days, SGI had "turned over" OpenGL to what was then the Architectural Review Board so couldn't dictate or control the API itself.

            Later when the ARB_multitexture extension was added to OpenGL 1.3, it added yet another selector glActiveTexture.

            There wasn't really a conscious decision to be so dependent on selectors in the OpenGL API. It just kind of happened.

            And once texture objects set the stage for a bind-to-edit model of operation, other extensions for buffers objects, framebuffer objects, etc. adopted the same bind-to-edit approach for consistency.

            The EXT_direct_state_access extension finally addressed this about 5 years ago. While the extension obviously required zero new hardware, it took the OpenGL working group a while to simply agree on the approach. Welcome to standards making by committee!

            I hope this helps.

            - Mark

            Comment


            • #7
              Originally posted by mark_kilgard View Post
              Actually back in the original OpenGL 1.0 days, there wasn't even the notion of texture objects. Instead there was only a current 1D and 2D texture target. The plan was that display lists could be used to "encapsulate" texture image state. That didn't work out very well and so texture objects were added in OpenGL 1.1 and the glBindTexture selector was introduced to minimize the API impact of supporting texture objects.

              The issue had nothing really to do with "SGI controlling the API". Even in OpenGL 1.0 days, SGI had "turned over" OpenGL to what was then the Architectural Review Board so couldn't dictate or control the API itself.

              Later when the ARB_multitexture extension was added to OpenGL 1.3, it added yet another selector glActiveTexture.

              There wasn't really a conscious decision to be so dependent on selectors in the OpenGL API. It just kind of happened.

              And once texture objects set the stage for a bind-to-edit model of operation, other extensions for buffers objects, framebuffer objects, etc. adopted the same bind-to-edit approach for consistency.

              The EXT_direct_state_access extension finally addressed this about 5 years ago. While the extension obviously required zero new hardware, it took the OpenGL working group a while to simply agree on the approach. Welcome to standards making by committee!

              I hope this helps.

              - Mark
              Thanks for the great explanation. Wow, this is what happens when you think more about the past (backwards compatibility) than the present and the future (proper code design).

              Comment


              • #8
                Originally posted by sarmad View Post
                Thanks for the great explanation. Wow, this is what happens when you think more about the past (backwards compatibility) than the present and the future (proper code design).
                We could have had a nice and clean overhaul full of immutable textures/buffers, DSA and C style OOP with Longs Peak, but unfortunately the CAD folks just said "FU, we don't want to rewrite our old code to get <modern feature>" and it all fell apart. Very unfortunate. And yet at the same time many of them are happy to swallow the D3D way of "version increase = API break" without complaining any bit.

                Comment


                • #9
                  Originally posted by Ancurio View Post
                  We could have had a nice and clean overhaul full of immutable textures/buffers, DSA and C style OOP with Longs Peak, but unfortunately the CAD folks just said "FU, we don't want to rewrite our old code to get <modern feature>" and it all fell apart. Very unfortunate. And yet at the same time many of them are happy to swallow the D3D way of "version increase = API break" without complaining any bit.
                  Whoa there; what a bunch of not-really-accurate history.

                  Long Peaks was in truth an absolute train wreck. Ill-informed web commentators often describe Long Peaks as being some "nice and clean overhaul" but that's so far from the truth. And "CAD folks" didn't have a vote or even any say on Long Peaks. They didn't ever even know what it was or care so it's ludicrous to say they subverted Long Peaks. Long Peaks was bad enough to subvert itself; it planned to be an incompatible API that was less functional and burdened with a bunch of dubious, unproven, inflexible API constructs. Multiple companies (but none CAD vendors) looked into the abyss that was Long Peaks and put an end to it.

                  Honestly, what's more plausible: There was this wonderfully clean overhaul of OpenGL poised for success and a few CAD companies not even involved in the process said "we don't want to rewrite our code" and... crash, boom, bam, this amazingly awesome API "just fell apart"... OR multiple rational companies involved in the process looked at what the Long Peaks effort had produced and weighed the unproven benefits against breaking API compatibility and quite sanely and responsibly realized Long Peaks was unjustified and canned it.

                  The latter isn't just more plausible; it's what happened.

                  - Mark

                  Comment


                  • #10
                    Originally posted by mark_kilgard View Post
                    Whoa there; what a bunch of not-really-accurate history.

                    Long Peaks was in truth an absolute train wreck. Ill-informed web commentators often describe Long Peaks as being some "nice and clean overhaul" but that's so far from the truth. And "CAD folks" didn't have a vote or even any say on Long Peaks. They didn't ever even know what it was or care so it's ludicrous to say they subverted Long Peaks. Long Peaks was bad enough to subvert itself; it planned to be an incompatible API that was less functional and burdened with a bunch of dubious, unproven, inflexible API constructs. Multiple companies (but none CAD vendors) looked into the abyss that was Long Peaks and put an end to it.

                    Honestly, what's more plausible: There was this wonderfully clean overhaul of OpenGL poised for success and a few CAD companies not even involved in the process said "we don't want to rewrite our code" and... crash, boom, bam, this amazingly awesome API "just fell apart"... OR multiple rational companies involved in the process looked at what the Long Peaks effort had produced and weighed the unproven benefits against breaking API compatibility and quite sanely and responsibly realized Long Peaks was unjustified and canned it.

                    The latter isn't just more plausible; it's what happened.

                    - Mark
                    Then why would they keep complete silence over what happened? Seems kind of strange for an open consortium, doesn't it?

                    Comment

                    Working...
                    X