Announcement

Collapse
No announcement yet.

Mesa RADV vs. AMDVLK Radeon Vulkan Performance For July 2021

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

  • #41
    Originally posted by agd5f View Post
    Don't like AMDVLK, don't use it. No one is forcing you to. There are some customers that want it. Would you prefer if it were closed source? And before someone suggests it, getting rid of AMDVLK does not suddenly free up a pile of developers to work on something else. That team still has to support other OSes and APIs; Linux is just a small part of what they work on. PAL for example is used by more than just Vulkan.
    One thing i don't understand is why AMDVLK and respectively Pro are so late about supporting features. Supporting features in a timely manner is not important because Linux is a lesser platform?

    Or like Pro package releases being more frequent is not needed because Linux is a lesser platform? Ray tracing appeared pretty late on Pro package and it can't even run Metro Exodus RT on Linux port reliably, stuff like Doom Eternal RT are probably out of question for Gpu Pro package+Proton combo. (Both titles works fine on Nvidia Linux btw )

    Does all man power goes to Windows driver and D3D?

    Comment


    • #42
      Originally posted by user1 View Post

      I didn't talk specifically about Steam Deck, but their attitude towards bug reports. As I said, they're barely getting fixed. And it's not just about performance, but also in-game glitches, general instability / bugs that crash the kernel. As you can see in these tests, not every game was even able to start with AMDVLK.
      Post a bug report on AMDVLK and post a bug report on RADV(Mesa), you will understand pretty damn fast why everyone focus on RADV. That aside AMDVLK is AMD responsibility not Valve/Feral/GOG/etc.

      Also is extremely dumb to waste developer time that could go into Proton/Wine/anti cheat support in fixing a 2nd Vulkan driver that is inferior to RADV in any measurable way, hence is great Valve is doing the smart thing.

      Please also note Valve won't fix issues with nVidia drivers either(i assume they are big enough for nVidia to allow them some sort of NDA access if Valve really wanted to)

      Comment


      • #43
        Originally posted by Leopard View Post

        Does all man power goes to Windows driver and D3D?
        My money is on 135% absolutely yes, as a business that is the sound decision since is where their brute sales come from and Consoles ofc, everything else is second priority

        Comment


        • #44
          Originally posted by jrch2k8 View Post

          Well i still don't see any reason to waste dev time on it but i guess it could be a cool project for someone someday
          I actually doubt it's even possible because ACO is part of Mesa, so it's designed to work with the other Mesa components like NIR. Unless someone will make it work outside of Mesa (if that's even possible), it can't just work in other driver implementations.
          Also, since AMDVLK is AMD's official Vulkan driver and its development model is not as open as Mesa, I don't think they will accept ACO, because they've already put a lot of effort into LLVM.

          Comment


          • #45
            Originally posted by pal666 View Post
            actually it exists for one reason: amd has to cater for all of their userbase, not just for 1% of linux users
            i meant clearly FOSS AMDVLK, closed AMDVLK is obvious why it exists.

            Also purely speaking about Vulkan i think RADV has way bigger userbase than closed AMDVLK since Vulkan hasn't been adapted too widely on enterprise software yet.

            Comment


            • #46
              Originally posted by user1 View Post

              I actually doubt it's even possible because ACO is part of Mesa, so it's designed to work with the other Mesa components like NIR. Unless someone will make it work outside of Mesa (if that's even possible), it can't just work in other driver implementations.
              Also, since AMDVLK is AMD's official Vulkan driver and its development model is not as open as Mesa, I don't think they will accept ACO, because they've already put a lot of effort into LLVM.
              ACO from what i've seen is pretty isolated, so in theory is doable but i'm sure it would require a fork.

              Comment


              • #47
                Originally posted by ResponseWriter View Post
                Does anyone else experience a cycle of GPU resets with recent LLVM 13.0 dev builds? LLVM builds prior to around a month ago (when this started happening) seem to work even if I use git builds elsewhere. Using KDE, kernel 5.13 and mesa-git on a 6800 XT.
                Offtopic but yes - I also had GPU reset issues using LLVM 13 and mesa-git recently though only with OpenGL games. Vulkan/DXVK and even the games having issues but using zink were working fine. Switched back to LLVM 12 and the issue was gone. Just today I switched back to LLVM 13 git though and so far I did not have a reset.

                Comment


                • #48
                  Originally posted by jrch2k8 View Post

                  Post a bug report on AMDVLK and post a bug report on RADV(Mesa), you will understand pretty damn fast why everyone focus on RADV. That aside AMDVLK is AMD responsibility not Valve/Feral/GOG/etc.

                  Also is extremely dumb to waste developer time that could go into Proton/Wine/anti cheat support in fixing a 2nd Vulkan driver that is inferior to RADV in any measurable way, hence is great Valve is doing the smart thing.

                  Please also note Valve won't fix issues with nVidia drivers either(i assume they are big enough for nVidia to allow them some sort of NDA access if Valve really wanted to)
                  Yeah, I know that AMDVLK is solely AMD's responsibility, that's what I said in one of my previous comments.

                  But one thing I don't understand is that on one hand, judging by their attitude to bug reports, it seems they don't really care about Linux gamer's needs. On the other hand, they actually do some game specific optimizations from time to time, on very rare occasions even to some Proton/DXVK games.
                  This makes me think they simply do it out of necessity, for the sake of being the "official open source solution", while in practice, the driver itself is mainly designed to work well for Stadia and some other special use cases.
                  Last edited by user1; 23 July 2021, 05:11 PM.

                  Comment


                  • #49
                    Originally posted by user1 View Post

                    Yeah, I know that AMDVLK is solely AMD's responsibility, that's what I said in one of my previous comments.

                    But one thing I don't understand is that on one hand, judging by their attitude to bug reports, it seems they don't really care about Linux gamer's needs. On the other hand, they actually do some game specific optimizations from time to time, on very rare occasions even to some Proton/DXVK games.
                    This makes me think they simply do it out of necessity, for the sake of being the "official open source solution", while in practice, the driver itself is mainly designed to work well for Stadia and some other special use cases.
                    Ok, now i get you and yes you are 100% right.

                    Comment


                    • #50
                      Originally posted by clouddrop View Post

                      Offtopic but yes - I also had GPU reset issues using LLVM 13 and mesa-git recently though only with OpenGL games. Vulkan/DXVK and even the games having issues but using zink were working fine. Switched back to LLVM 12 and the issue was gone. Just today I switched back to LLVM 13 git though and so far I did not have a reset.
                      LLVM-git is a minefield, i'm not sure which distro you guys use but is always good idea to keep your package manager cache until you are sure all is working then you clean it.

                      In my case i always keep the previous LLVM on /var/cache/pacman in case something goes wrong with an update

                      Comment

                      Working...
                      X