Announcement

Collapse
No announcement yet.

Mesa 19.0 RADV vs. AMDVLK 2019.Q1.2 vs. Radeon Software 18.50 Linux Vulkan Performance

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

  • Mesa 19.0 RADV vs. AMDVLK 2019.Q1.2 vs. Radeon Software 18.50 Linux Vulkan Performance

    Phoronix: Mesa 19.0 RADV vs. AMDVLK 2019.Q1.2 vs. Radeon Software 18.50 Linux Vulkan Performance

    With the latest AMDVLK Vulkan driver improvements back to coming out on a weekly basis by AMD and Mesa 19.0 development progressing ahead of its feature freeze later this month, here is a fresh Linux gaming benchmark comparison of the AMD Radeon Vulkan driver options on Linux. Tested this round with a Radeon RX 590 and RX Vega 64 was the latest Mesa 19.0 development state for RADV, this week's new AMDVLK 2019.Q1.2 driver snapshot, and the Radeon Software 18.50 proprietary driver while running a slew of Vulkan-powered Linux games and DXVK.

    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
    Michael, do you think you could increase the font size a little bit (perhaps just 1 or 2 pixels or points) for the minimum/maximum fps? It's a bit fuzzy right now, so the characters tends to smosh together. The minimum/maximum values should perhaps be a bit more emphasized, since the minimum frame-rate is a quite deciding factor whether a game is playable or not.
    Thanks for a good article!

    Comment


    • #3
      As an AMD user I'm really glad radv exists. Sadly AMDVLK has been rather disappointing. It took forever to get release, and when it finally did, it could render bearly anything correctly. Even now, more then a year later, it still remains less reliable, especially with dxvk. Also the "code drop maybe once a week" development model means that end-users can't test new features ahead of an offical release even if the code already exists internally (https://github.com/GPUOpen-Drivers/AMDVLK/issues/70). If there was no radv amd users would still be completely without VK_EXT_transform_feedback.

      Anyways, what i actually wanted to say: I'm happy radv's performance remains competitive and thanks to the devs involved.

      Comment


      • #4
        Originally posted by Masush5 View Post
        As an AMD user I'm really glad radv exists. Sadly AMDVLK has been rather disappointing. It took forever to get release, and when it finally did, it could render bearly anything correctly. Even now, more then a year later, it still remains less reliable, especially with dxvk. Also the "code drop maybe once a week" development model means that end-users can't test new features ahead of an offical release even if the code already exists internally (https://github.com/GPUOpen-Drivers/AMDVLK/issues/70). If there was no radv amd users would still be completely without VK_EXT_transform_feedback.

        Anyways, what i actually wanted to say: I'm happy radv's performance remains competitive and thanks to the devs involved.
        I totally agree, RADV is very stable and I always had a great experience even when I used mesa-git! So yes, thank you for this great driver :-) And I hope I can rely more on this in the future, maybe Zink/VK9/DXUP or something else like kwin-vulkan will further extend my RADV usage.

        Comment


        • #5
          I think it's clear at this point RADV is the way to go. It's the "supported" backend by most projects (as in tested and working right) and has good development pace.

          Not saying AMDVLK needs to go of course. It's sad that AMD always manage to screw things up ending up with at minimum 2 "drivers" for the same thing. At least this time, there's one that's "good" and the other "ok". It used to be bad and worse

          Comment


          • #6
            It looks like only RADV was able to run all the games where AMDVLK and Radeon Software didn't. Time to end AMDVLK and focus on RADV.

            Comment


            • #7
              Originally posted by Dukenukemx View Post
              It looks like only RADV was able to run all the games where AMDVLK and Radeon Software didn't. Time to end AMDVLK and focus on RADV.
              I was thinking pretty much the same thing.
              I wish AMD would just port the remaining things from AMDVLK to RADV in the next months and then continue supporting only RADV.

              Comment


              • #8
                Originally posted by ihatemichael
                What is AMDVLK? Is this another Vulkan stack that plugs into Mesa, or is it completely separate from Mesa?
                Completely separate AFAIK.

                In regard to a previous comment, I don't think there is much that can be brought from AMDVLK to RADV. I do not work on either Vulkan stack, but this is what I've been told from a high level.

                Comment


                • #9
                  Yeah at this point AMD should just admit that AMDVLK is pointless and contribute to RADV.
                  Their stubbornness with AMDVLK as well as the amount of time they've taken to open-source it makes me wonder if they really wanted to have an open-source Vulkan driver at all.

                  Anyway, thanks again to all people contributing to RADV, your work is much appreciated

                  Comment


                  • #10
                    I don't agree that only RADV should the only Vulkan driver that matters, competition is rarely a bad thing. I can remember a time that ie 6 was the only browser that mattered. After having lived with fglrx while RadeonSI was evolving then discovering that AMDGPU-PRO was only available on select distros, I was very, very glad that there were choices. Later finding out that AMDGPU supported many cards that Radeon and allowed me to run Vulkan apps, I was once again pleased that there was a choice.

                    I'm just glad there is choice and excellent performing drivers for AMD video cards and why I keep buying AMD.

                    Comment

                    Working...
                    X