Announcement

Collapse
No announcement yet.

Guillemot: Various OpenGL Tips & Tricks

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

  • Guillemot: Various OpenGL Tips & Tricks

    Phoronix: Guillemot: Various OpenGL Tips & Tricks

    For those invested in OpenGL and don't want to abandon it so soon for Vulkan, a few Phoronix readers pointed out a blog post this week filled with various OpenGL rendering tips and tricks...

    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
    Anyone who have a project which is already in development or in production should not bother to rewrite it/wrap it with Vulkan. They should rather apply AZDO and get ~95% of the performance gains for very minimal effort. Then use Vulkan directly for new projects going forward.

    -----

    Reading this blog post was a real disappointment. Writing a renderer is all about efficiency, so designing a data model based on ideas from relational databases seems odd, considering they are known to be very inefficient for performance critical workloads. Having a renderer which on each frame assembles the scene by searching(!) for each object instead of using a direct pointer is inexcusable, that's simply beyond anything rational. (double facepalm)

    I don't know what the kids are taught in school these days, but this is one of the most inefficient renderers I've seen in a while. Most of it is just pure overhead, and it scored a full jackpot of over-engineering. There is no need to regenerate all of these structures for every single render, it should be offloaded and changed on demand, no on render. It's a common problem with coders these days; they get a task and immediately start applying all sorts of design patterns (most of which they don't understand), as if applying patterns were a goal by itself, instead of focusing on the actual problem.

    Beginners should start off by watching this talk by Mike Acton. Understanding the problem is where any developer should start before building a "solution".

    Comment


    • #3
      Originally posted by efikkan View Post
      Anyone who have a project which is already in development or in production should not bother to rewrite it/wrap it with Vulkan. They should rather apply AZDO and get ~95% of the performance gains for very minimal effort. Then use Vulkan directly for new projects going forward.

      -----

      Reading this blog post was a real disappointment. Writing a renderer is all about efficiency, so designing a data model based on ideas from relational databases seems odd, considering they are known to be very inefficient for performance critical workloads. Having a renderer which on each frame assembles the scene by searching(!) for each object instead of using a direct pointer is inexcusable, that's simply beyond anything rational. (double facepalm)

      I don't know what the kids are taught in school these days, but this is one of the most inefficient renderers I've seen in a while. Most of it is just pure overhead, and it scored a full jackpot of over-engineering. There is no need to regenerate all of these structures for every single render, it should be offloaded and changed on demand, no on render. It's a common problem with coders these days; they get a task and immediately start applying all sorts of design patterns (most of which they don't understand), as if applying patterns were a goal by itself, instead of focusing on the actual problem.

      Beginners should start off by watching this talk by Mike Acton. Understanding the problem is where any developer should start before building a "solution".
      I think you have been confused by his mental model. After all a "direct pointer" can be seen as a key into a database/container.

      Comment


      • #4
        Originally posted by log0 View Post
        I think you have been confused by his mental model. After all a "direct pointer" can be seen as a key into a database/container.
        If you look at the code you'll see it's performing a search to find each ID. Immediately I can see this implementation will suffer terribly from data cache misses, a lot of branching which causes mispredictions and code cache misses, and also all the unnecessary code logic. This CPU code will run at less than 0.1% efficiency, especially as cache misses increases with just a few more "objects". The most simple and efficient improvement is to remove this "key lookup" all together; it's not needed at all. It's a bloated and fancy way to generate something you basically already know. Secondly, separate any logic that doesn't belong in the rendering logic, since there is no need to "rebuild" everything per frame. When the scene changes, you update what changes, not the whole world. In the end the rendering function should just work on a tightly packed array of IDs needed by the rendering API, so there will be basically no cache misses or unnecessary logic.

        And all of that is without even considering the usage of the graphics API. Additionally there's a lot of redundant state changes, lack of efficient batching, etc. This renderer is built to render "anything" in the most naive way, which is a typical way people are taught to design things in academia. This renderer will simply not scale when the data increases.

        Comment


        • #5
          Originally posted by efikkan View Post
          Anyone who have a project which is already in development or in production should not bother to rewrite it/wrap it with Vulkan. They should rather apply AZDO and get ~95% of the performance gains for very minimal effort. Then use Vulkan directly for new projects going forward.

          -----

          Reading this blog post was a real disappointment. Writing a renderer is all about efficiency, so designing a data model based on ideas from relational databases seems odd, considering they are known to be very inefficient for performance critical workloads. Having a renderer which on each frame assembles the scene by searching(!) for each object instead of using a direct pointer is inexcusable, that's simply beyond anything rational. (double facepalm)

          I don't know what the kids are taught in school these days, but this is one of the most inefficient renderers I've seen in a while. Most of it is just pure overhead, and it scored a full jackpot of over-engineering. There is no need to regenerate all of these structures for every single render, it should be offloaded and changed on demand, no on render. It's a common problem with coders these days; they get a task and immediately start applying all sorts of design patterns (most of which they don't understand), as if applying patterns were a goal by itself, instead of focusing on the actual problem.

          Beginners should start off by watching this talk by Mike Acton. Understanding the problem is where any developer should start before building a "solution".
          Thank you for bringing up Mike Acton and Data Oriented Design. It's the first thing I think about these days when I see a headline that say "Designing an engine" or something along those lines. I'm a graphics programmer and the entire industry is going in that direction, including DICE (FrostBite), OGRE (as a project that Acton brought up as an example in his talk) and many others. I recommend watching the "Ashes of Singularity" talk by Dan Baker from GDC 2016, it's very very inspiring.

          Another extremely relevant talk is Herb Sutter's talks on concurrency, modern C++ and modern design: https://youtu.be/TJHgp1ugKGM?t=23m30s

          You see that I've started it at 23 minutes, because after that he starts talking about concurrency and how important the cache is. At the end, he quotes a game developer, and the speedups he got from actually thinking about cache (and designing like Mike Acton).
          Last edited by Azpegath; 28 November 2016, 09:26 AM.

          Comment


          • #6
            Originally posted by Azpegath View Post
            Thank you for bringing up Mike Acton and Data Oriented Design. It's the first thing I think about these days when I see a headline that say "Designing an engine" or something along those lines. I'm a graphics programmer and the entire industry is going in that direction, including DICE (FrostBite), OGRE (as a project that Acton brought up as an example in his talk) and many others.
            I'm not a big fan of presentations because it's usually some guy trying to convince others about his superior "philosophical" idea of software development. I fairly recently came across the talk by Mike Acton, and I really liked it because it was a no-BS talk about what actually works and why people should have a "scientific approach" rather than a philosophical virtual model of the world. I find it interesting that my own experience from decades of coding with rendering, compilers and low-level programming is pretty much identical to the conclusions presented in the talk. I would assume other pragmatic people who are curious and do research will make similar conclusions.

            Here is a related talk from Scott Meyers: Cpu Caches and Why You Care.

            Originally posted by Azpegath View Post
            I recommend watching the "Ashes of Singularity" talk by Dan Baker from GDC 2016, it's very very inspiring.
            Can I find this anywhere without paying $500 over at GDC Vault?

            Originally posted by Azpegath View Post
            Another extremely relevant talk is Herb Sutter's talks on concurrency, modern C++ and modern design: https://youtu.be/TJHgp1ugKGM?t=23m30s

            You see that I've started it at 23 minutes, because after that he starts talking about concurrency and how important the cache is. At the end, he quotes a game developer, and the speedups he got from actually thinking about cache (and designing like Mike Acton).
            Thank you.

            I quickly threw together an experiment just to confirm this. Most game engines work with huge linear streams of small structures; events, game objects, etc. So I created a queue of events, each a struct of a few bytes. Coders are taught in school to think a queue should be implemented as some sort of a list. So when the elements in the list is intentionally not memory aligned, iteration of just 10.000 elements in an array will be >50 times faster than a linked list. So this is exactly like some of us expected.

            Comment

            Working...
            X