Announcement

Collapse
No announcement yet.

Valve's Mesa Developers Continue Tuning KHR_no_error For Saving CPU Cycles

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

  • Valve's Mesa Developers Continue Tuning KHR_no_error For Saving CPU Cycles

    Phoronix: Valve's Mesa Developers Continue Tuning KHR_no_error For Saving CPU Cycles

    Valve's developers working on the Mesa / Linux graphics driver stack continue tuning KHR_no_error for helping lower the CPU utilization in OpenGL bug-free games...

    http://www.phoronix.com/scan.php?pag...ontinue-Tuning

  • #2
    But for OpenGL bug-free games/applications
    Yup, for all 2 of them. Including GLXGears. :-D

    More seriously, writing bug-free code is hard.
    Don't hold hopes too high about lots of game engine code being bug free.

    On the other hand, it's "just graphics".
    Chances are high that on modern hardware (which features IOMMU and other forms of protection), invalid code that isn't caught because error checking is disabled, won't cause a crash of the GPU and taking down the whole bus with it, but more likely will cause graphical artifacts.
    Things that one could more or less live with.

    Also, this enables the possibility of doing the QA with the error checking turned in (so the game devs can find code and situation that could raise undefined behaviour) and then do the release with error checking turned off, to gain a little bit more performance.
    Vulkan API is designed from the ground up for such development cycles.

    Comment


    • #3
      OpenGL bug-free DDDD LOL

      Though seriously. Just disable the debug overhead when you aren't debugging.

      Comment


      • #4
        Is there a Vulkan equivalent of mesamatrix out there? Because to my understanding, even the closed-source drivers don't have 100% of the Vulkan functions/features.

        Comment


        • #5
          Originally posted by DrYak View Post

          Yup, for all 2 of them. Including GLXGears. :-D

          More seriously, writing bug-free code is hard.
          Don't hold hopes too high about lots of game engine code being bug free.

          On the other hand, it's "just graphics".
          Chances are high that on modern hardware (which features IOMMU and other forms of protection), invalid code that isn't caught because error checking is disabled, won't cause a crash of the GPU and taking down the whole bus with it, but more likely will cause graphical artifacts.
          Things that one could more or less live with.

          Also, this enables the possibility of doing the QA with the error checking turned in (so the game devs can find code and situation that could raise undefined behaviour) and then do the release with error checking turned off, to gain a little bit more performance.
          Vulkan API is designed from the ground up for such development cycles.
          Typically drivers have GPU reset functionality anyway. This actually makes me wonder if DX11 drivers do exactly this as in don't even try to sanitize things to avoid GPU crash but then just reset it and continue. I've occasionally been seeing this kind of behaviour in games on Windows

          Comment


          • #6
            Originally posted by DrYak View Post
            More seriously, writing bug-free code is hard.
            article is not about completely bug-free code, but about allowed arguments to opengl functions

            Comment


            • #7
              Originally posted by DrYak View Post

              Yup, for all 2 of them. Including GLXGears. :-D

              More seriously, writing bug-free code is hard.
              Don't hold hopes too high about lots of game engine code being bug free.
              Most games I've tested have been fine so far. To put this extension in perspective this is what Vulkan does by default, validation is done in a layer that is run during development. For OpenGL dev's must request validation be turned off using this extension.

              Comment


              • #8
                Yeah, I agree with DrYak - there's only a 0.001% chance that the game you're running doesn't have a bug that will cause major problems.
                ​​​​

                Comment


                • #9
                  Probably higher than that, isn't it ? AFAIK most of the Mesa drivers are fairly verbose when they see problems, so if the drivers aren't returning error messages to the app I would expect it to be safe with this option enabled.

                  That said, there are apps which generate errors and ignore them (don't even log them), not sure if there is an easy way to arrange for errors to be displayed/logged outside the app so you know for sure what is going on. There are LIBGL_DEBUG and MESA_DEBUG environment variables which might be sufficient.

                  Comment


                  • #10
                    Originally posted by DrYak View Post
                    Yup, for all 2 of them. Including GLXGears. :-D

                    More seriously, writing bug-free code is hard.
                    Don't hold hopes too high about lots of game engine code being bug free.

                    On the other hand, it's "just graphics".
                    Chances are high that on modern hardware (which features IOMMU and other forms of protection), invalid code that isn't caught because error checking is disabled, won't cause a crash of the GPU and taking down the whole bus with it, but more likely will cause graphical artifacts.
                    Things that one could more or less live with.

                    Also, this enables the possibility of doing the QA with the error checking turned in (so the game devs can find code and situation that could raise undefined behaviour) and then do the release with error checking turned off, to gain a little bit more performance.
                    Vulkan API is designed from the ground up for such development cycles.
                    I forced this option on for my whole X session, and the only thing which failed was blender (fails whenever a context menu is closed). It is perfectly possible to completely avoid GL errors except in the most fringe of scenarios, most GL application developers try to do this anyway.

                    Comment

                    Working...
                    X