Page 1 of 2 12 LastLast
Results 1 to 10 of 14

Thread: Recapping The OpenGL 4.5 Improvements, NVIDIA Linux Changes

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

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

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

  2. #2
    Join Date
    Apr 2011
    Location
    Finland
    Posts
    22

    Default Deslided presentation


  3. #3
    Join Date
    Jul 2013
    Posts
    339

    Default

    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?

  4. #4
    Join Date
    Jan 2009
    Posts
    625

    Default

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

  5. #5

    Default Talk replay available

    Quote 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

  6. #6

    Default

    Quote 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

  7. #7
    Join Date
    Jul 2013
    Posts
    339

    Default

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

  8. #8
    Join Date
    Aug 2011
    Posts
    541

    Default

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

  9. #9

    Default

    Quote 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

  10. #10
    Join Date
    Aug 2011
    Posts
    541

    Default

    Quote 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?

Posting Permissions

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