Announcement

Collapse
No announcement yet.

Benchmarking Valve's RADV+ACO Yields Fastest Open-Source Radeon Vulkan Driver

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

  • Benchmarking Valve's RADV+ACO Yields Fastest Open-Source Radeon Vulkan Driver

    Phoronix: Benchmarking Valve's RADV+ACO Yields Fastest Open-Source Radeon Vulkan Driver

    Last week Valve formally announced their new Radeon shader compiler for AMD's open-source Linux graphics drivers. At this stage it's an out-of-tree solution providing generally faster performance to the Mesa RADV Vulkan driver over the current AMDGPU LLVM shader compiler but they also have ambitions of wiring it up to the RadeonSI OpenGL driver once mature too, assuming AMD's developers are willing to make use of this new compiler code. For those wondering about the Vulkan performance, here are our independent benchmarks of the current Mesa 19.2 RADV performance with the LLVM shader compiler compared to Valve's new "ACO" compiler back-end and then also using AMD's official AMDVLK reference driver that is also leveraging LLVM.

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

  • #2
    You forgot about AMDGPU-PRO (which uses PAL).

    Comment


    • #3
      Originally posted by tildearrow View Post
      You forgot about AMDGPU-PRO (which uses PAL).
      No pro 19.04 support.
      Michael Larabel
      http://www.michaellarabel.com/

      Comment


      • #4
        Why harmonic?

        Comment


        • #5
          AMD should make themselves honest that the open amdvlk strategy didn't work out. There was very little reason to use this driver and, as long as radv won't struggle with navi, it seems there will even be less reason to do so in the near future. Why should Stadia use it?
          (I don't want to really open that bottle as well, but I guess similar things could be said about their Linux OpenCL drivers, at least from a consumer/enduser perspective..)

          Comment


          • #6
            I'd like to see it just get merged into Mesa master but have it default to the llvm shader compiler, allowing us to set the env variable of RADV_PERFTEST=aco until it is more mature to flip on default. The aco branch hasn't had updates since July 5th so it's diverged a little bit from master.

            I've been using it myself and noticed big improvements in stutter and overall fps in Talos Principle, along with some of the others you mentioned. DXVK/Steam Play games also. It's good stuff.

            Comment


            • #7
              Originally posted by pkunk View Post
              Why harmonic?
              You can see geometric from the OpenB enchmarking.org link if desired, but when all the results are in FPS, harmonic makes the most sense (compared to geometric with different scales)
              Michael Larabel
              http://www.michaellarabel.com/

              Comment


              • #8
                Originally posted by aufkrawall View Post
                AMD should make themselves honest that the open amdvlk strategy didn't work out.
                When do you take off your pink glasses? The results show that no driver has a significant advantage.
                There are still no tests of native games. Ports and Steam Play only.

                Originally posted by aufkrawall View Post
                Why should Stadia use it?
                Why not? Having full access to proprietary tools, support from the first development team, day-0 fixes - that's what you need for the development of such a project.

                Comment


                • #9
                  BNieuwenhuizen samuel Does ACO generate different binaries than current LLVM solution for the same shader? AFAIU, this falls in the "best code generation" part of the news

                  Comment


                  • #10
                    Originally posted by mphuZ View Post
                    When do you take off your pink glasses? The results show that no driver has a significant advantage.
                    There are still no tests of native games. Ports and Steam Play only.
                    You accidentally prove yourself wrong: When amdvlk isn't faster, there is no need for a notoriously immature driver outside of mesa.

                    Originally posted by mphuZ View Post
                    Why not? Having full access to proprietary tools, support from the first development team, day-0 fixes - that's what you need for the development of such a project.
                    And that wasn't the case with radv and the Feral ports?

                    Comment

                    Working...
                    X