Announcement

Collapse
No announcement yet.

KHR_no_error Patches Posted For Mesa In Quest To Finding More Performance

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

  • KHR_no_error Patches Posted For Mesa In Quest To Finding More Performance

    Phoronix: KHR_no_error Patches Posted For Mesa In Quest To Finding More Performance

    Timothy Arceri, working for Valve on the open-source Mesa graphics stack primarily around Radeon hardware support, has posted early patches on his latest OpenGL extension upbringing...

    http://www.phoronix.com/scan.php?pag...C-KHR-No-Error

  • #2
    For what it's worth, it's pretty hard to separate out the validation code in these GL calls, that's most of the work involved. It will take a lot of work to get a meaningful performance gain from this.

    Could be good though, especially for things like compositors which have relatively little interaction with GL.

    Comment


    • #3
      Originally posted by microcode View Post
      For what it's worth, it's pretty hard to separate out the validation code in these GL calls
      Do you happen to know how much time Mesa spends validating GL calls in proportion to doing the actual work?

      Good stuff though, might eventually help my ancient CPU a bit.

      Comment


      • #4
        Originally posted by VikingGe View Post
        help my ancient CPU a bit.
        Indeed, it will free one bit no longer needing to be in cache.

        Comment


        • #5
          Originally posted by microcode View Post
          For what it's worth, it's pretty hard to separate out the validation code in these GL calls, that's most of the work involved. It will take a lot of work to get a meaningful performance gain from this.
          From the application or driver developers? Because if I remember correctly one of the big performance boosting features of Vulkan was that to reduce CPU overhead they made most of the driver side validation optional functionality that would only really be used by developers during development. If they can achieve the same thing on OpenGL then it would definitely be nice.

          This is obviously meant for VR, which Valve is heavily invested in, as it requires consistently low frame times and this should help achieve that. Avoidable overheads and specially unpredictable ones are the absolute last thing you want when you're doing VR.
          "Why should I want to make anything up? Life's bad enough as it is without wanting to invent any more of it."

          Comment


          • #6
            This is one of the most important year-2017 Mesa patches for enabling higher performance with stable OpenGL apps on relatively-low-IPC CPUs, such as on AMD's Bulldozer&descendants CPUs. @tarceri

            (IPC = Instructions Per Clock)

            Comment


            • #7
              Originally posted by L_A_G View Post
              Because if I remember correctly one of the big performance boosting features of Vulkan was that to reduce CPU overhead they made most of the driver side validation optional functionality that would only really be used by developers during development.
              if your application is triggering OpenGL errors, you're usually doing something horribly wrong. Even if you haven't ever developed anything using OGL, just read the docs, it's full of "this will trigger GL_INVALID_OPERATION if you're doing texture operations on an object that isn't a texture". Vulkan just assumes you're not an idiot and provides validation layers. If you're still doing things wrong... well, people will complain about GPU hangs.

              Comment


              • #8
                Originally posted by VikingGe View Post
                if your application is triggering OpenGL errors, you're usually doing something horribly wrong. Even if you haven't ever developed anything using OGL, just read the docs, it's full of "this will trigger GL_INVALID_OPERATION if you're doing texture operations on an object that isn't a texture". Vulkan just assumes you're not an idiot and provides validation layers. If you're still doing things wrong... well, people will complain about GPU hangs.
                The thing about the validation layers is that they're mostly useful for the developers of the application. The end users won't have the skills necessary to debug and fix the application and with proprietary software like games the developers obviously don't even want for them to have access to the source code.

                Theoretically at least the debugging should be done and the application should work completely without issues before the end user gets their hands on them.
                "Why should I want to make anything up? Life's bad enough as it is without wanting to invent any more of it."

                Comment


                • #9
                  Originally posted by L_A_G View Post
                  The thing about the validation layers is that they're mostly useful for the developers of the application. The end users won't have the skills necessary to debug and fix the application and with proprietary software like games the developers obviously don't even want for them to have access to the source code.

                  Theoretically at least the debugging should be done and the application should work completely without issues before the end user gets their hands on them.
                  The end user has the full ability to use layers. They can use the validation layers (useful for developers mainly, as you said), but they can also use custom layers. This means that if you have an out-of-support binary program which has a bug which is triggered when it is used with a newer Vulkan driver, you could technically shim the bug-inducing calls in some way to work around them. Really there are many excellent use cases for layers.

                  Comment


                  • #10
                    Originally posted by L_A_G View Post
                    From the application or driver developers?
                    I meant work for the driver developers. Application developers are already mostly "done" in OpenGL. Their code shouldn't have been triggering OpenGL errors to begin with, so enabling this should have no impact on stability (fingers crossed).

                    Comment

                    Working...
                    X