Announcement

Collapse
No announcement yet.

Mesa's RADV Vulkan Driver Holds A Narrowing Lead Over AMDVLK With Ubuntu 21.10 On Wayland

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

  • #21
    Originally posted by mphuZ View Post

    Aren't you interested in seeing such a test?
    I am. But specifically those tests from 2019 are irrelevant today, because of the reasons I mentioned in my previous comment.

    Comment


    • #22
      Originally posted by mphuZ View Post

      I would like to see a test like this: https://gist.github.com/pendingchaos...089f29a8c6aa63
      As you can see, even the ACO was inferior to the proprietary compiler in this test. I want to see the actual figures.
      I have some more: replaying this fossilize archive (which basically compiles a bunch of recorded vulkan pipelines) https://drive.google.com/file/d/1c1H...ew?usp=sharing
      With fossilize-replay from https://github.com/ValveSoftware/Fossilize
      `time fossilize-replay --num-threads 1 rpcs3-fossilize.a342c755b5f2aa72.1.foz`:
      amdvlk: 115,88 secs
      amdgpu-pro: 32,51 secs
      radv/aco: 10,81 secs

      Comment


      • #23
        Originally posted by Masush5 View Post

        I have some more: replaying this fossilize archive (which basically compiles a bunch of recorded vulkan pipelines) https://drive.google.com/file/d/1c1H...ew?usp=sharing
        With fossilize-replay from https://github.com/ValveSoftware/Fossilize
        `time fossilize-replay --num-threads 1 rpcs3-fossilize.a342c755b5f2aa72.1.foz`:
        amdvlk: 115,88 secs
        amdgpu-pro: 32,51 secs
        radv/aco: 10,81 secs
        I didn't test shader compile time myself, but that's exactly how I felt when I tested all 3 compilers in a shader heavy DXVK game. ACO was the fastest, and Pro compiler was much closer to ACO performance than to LLVM.
        Last edited by user1; 30 December 2021, 03:38 PM.

        Comment


        • #24
          Originally posted by Masush5 View Post

          I have some more: replaying this fossilize archive (which basically compiles a bunch of recorded vulkan pipelines) https://drive.google.com/file/d/1c1H...ew?usp=sharing
          With fossilize-replay from https://github.com/ValveSoftware/Fossilize
          `time fossilize-replay --num-threads 1 rpcs3-fossilize.a342c755b5f2aa72.1.foz`:
          amdvlk: 115,88 secs
          amdgpu-pro: 32,51 secs
          radv/aco: 10,81 secs
          Thanks for all these examples!

          One more comment on shader caches: It *can* play a role even if no caches exist when starting the application. The key is, that compilers compile complete pipelines, but can cache shaders that are reused between pipelines (under some premises, I think the pipeline descriptor layout needs to be the same). If a game reuses a pixel or vertex shader in a lot of pipelines, caching the compilation results makes a noticeable difference

          Comment


          • #25
            mphuZ

            Couldn't you have used your Asperger-Syndrome to specialize in anything else other than the POS driver that is AMDVLK?

            Google was foolish enough to settle on it for Stadia instead of choosing the objectively superior RADV solution that would have allowed them to actually improve the performance of their nowadays aging server-grade VEGA56 over time.

            But since Stadia will most likely get abandoned in 2022 anyway (hey, it is still a Google product after all), it doesn't matter anyway.

            Just too bad about all the lost manpower that could have gone into boosting RADV even further [to help the Steam Deck]...

            Comment


            • #26
              Originally posted by skeevy420 View Post

              Because Polaris was the last AMD GPU we could buy before Crypto and NFT drove prices to ridiculous levels. If you're like me and $200-300 for an RX 580 was a big purchase, you ain't gonna spend $500-600 on a 6600XT...pretty much the one GPU they've released that can be considered to be the upgrade path for the cheap-asses who stick to mid-range or lower cards.
              Not only that, but POLARIS was sold as AMDs low to medium end discrete architecture for a very long time. You can still buy new RX 580s on Amazon! Personally, value has to improve a lot for me to upgrade from my POLARIS card for the foreseeable future. Sure, I'd love a 6900 XT, if someone want to buy me one!

              I am concerned POLARIS is being neglected now by AMD, even within Mesa. The lack of modifier support for GFX8 is extremely problematic for direct scanout, and prevents the use of Vulkan compositors.

              Comment


              • #27
                Originally posted by user1 View Post

                Well yeah.. I understand the current GPU situation very well. My point is that the QA of PAL drivers (DX12 and AMDVLK) seems lacking on Polaris, even though it's the most popular AMD architecture, so AMD should put more effort into it. I mean I haven't even heard about cases when Vulkan extensions just break in any other Vulkan driver.
                Can't say I disagree there. Frankly, I think they maintain too much and they're not the best open source stewards. By that I mean things like how Intel doesn't have 3 Vulkan drivers and how they do giant ass code dumps instead of individual commits.

                I'd shit a brick if AMD contributed AOCC/their LLVM tweaks to Intel's oneAPI. (The joke is it can't technically be "oneAPI" if AMD has AOCC)

                Comment


                • #28
                  Originally posted by s_j_newbury View Post

                  Not only that, but POLARIS was sold as AMDs low to medium end discrete architecture for a very long time. You can still buy new RX 580s on Amazon! Personally, value has to improve a lot for me to upgrade from my POLARIS card for the foreseeable future. Sure, I'd love a 6900 XT, if someone want to buy me one!

                  I am concerned POLARIS is being neglected now by AMD, even within Mesa. The lack of modifier support for GFX8 is extremely problematic for direct scanout, and prevents the use of Vulkan compositors.
                  I feel like they're stretched thin so they focus as much as possible on their current gen GPUs and everything else gets pushed to the back burner. It really seemed that way during the initial Radeon>AMDGPU bringup when some GPUs like the 290x had lots of people reporting issues that never got fixed...most every premium card from before Polaris is in the same boat. Vega would probably be in that boat if it weren't for all the Vega APUs.

                  Comment


                  • #29
                    Originally posted by Linuxxx View Post
                    mphuZ
                    Google was foolish enough to settle on it for Stadia instead of choosing the objectively superior RADV solution that would have allowed them to actually improve the performance of
                    The best for whom? For you or game developers?
                    Are you ready to commit to supporting AMD graphics cards programmatically? All major platforms enjoy the full support of the hardware manufacturer (except Valve) and so far nothing bad has come of it.

                    Comment


                    • #30
                      both RADV and AMDVLK have their advantages. and considering that they are both userspace driver that can co-exist, they were probably using both drivers depending on the game, I doubt setting up a per-game profile is much of an issue is there any evidence to suggest they didn't use both? and exclusively used AMDVLK?

                      Comment

                      Working...
                      X