Announcement

Collapse
No announcement yet.

Testing RADV's Out-of-Order Rasterization Vulkan Performance

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

  • Testing RADV's Out-of-Order Rasterization Vulkan Performance

    Phoronix: Testing RADV's Out-of-Order Rasterization Vulkan Performance

    With the RADV Vulkan driver recently landing improvements to its out-of-order rasterization support, I ran some performance benchmarks of this non-default feature to see if it made much of a deal for today's Vulkan Linux games...

    http://www.phoronix.com/scan.php?pag...-of-Order-Test

  • #2
    A 1%-2% overall improvement is a great result for a single optimization!

    Comment


    • #3
      If there'd been any regression I'd call it a wash but cross the board is undoubtedly a success.

      Comment


      • #4
        2 frames here and 2 frames there, makes all the difference when added up!

        Comment


        • #5
          I'm curious if this has a greater effect on lower resolutions or worse hardware. Either way, great to see there's no regressions.

          Comment


          • #6
            What happened to the RadeonSI NIR benchmarking?

            Comment


            • #7
              So 1-3% performance gains and no regressions. Good job Valve!

              Comment


              • #8
                I appreciate all the hard work VALVe is putting into Linux graphics drivers so much. They're all awesome. I hope they know how awesome they are.

                Comment


                • #9
                  Originally posted by ethana2 View Post
                  I appreciate all the hard work VALVe is putting into Linux graphics drivers so much. They're all awesome. I hope they know how awesome they are.
                  But in the case of Vulkan it's a shame that they don't combine their efforts with the AMD devs. Would be nice if all the smart people were contributing to the same driver (I don't mind either RadV or amdvlk).

                  But I understand the reality that amdvlk codebase is needed for windows, and that the community including Red Hat, Valve etc had to act rather than wait for AMD.
                  Last edited by humbug; 04-15-2018, 03:12 AM.

                  Comment


                  • #10
                    Originally posted by humbug View Post
                    But in the case of Vulkan it's a shame that they don't combine their efforts with the AMD devs. Would be nice if all the smart people were contributing to the same driver (I don't mind either RadV or amdvlk).

                    But I understand the reality that amdvlk codebase is needed for windows, and that the community including Red Hat, Valve etc had to act rather than wait for AMD.
                    It would be better late than never, if they combined efforts.

                    Comment

                    Working...
                    X