Announcement

Collapse
No announcement yet.

Mesa RADV vs. AMDVLK Radeon Vulkan Performance For July 2021

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

  • #51
    Originally posted by F.Ultra View Post
    That and e.g the fact that games like Metro Exodus works flawless with AMDVLK but crashes hard on RADV (and it was on Stadia long before they sold the Linux version).
    If that still happens with the newest version of mesa, write a bug report. Some crashes in that game were fixed a few months ago.

    Comment


    • #52
      Originally posted by QuImUfu View Post
      If that still happens with the newest version of mesa, write a bug report. Some crashes in that game were fixed a few months ago.
      It doesn't happen. It was fixed long ago.

      Problem is; when devs doesn't test their game on RADV such issues are inevitable. Fwiw Metro Exodus fix came fast and works fine since this commit.

      https://gitlab.freedesktop.org/mesa/...8932ab57ad81dc

      Comment


      • #53
        Originally posted by QuImUfu View Post
        If that still happens with the newest version of mesa, write a bug report. Some crashes in that game were fixed a few months ago.
        Yes there where an early memory leak that where fixed months ago but there are some late game chapters where radv straight out crashes so I had to put in amdvlk instead. And I'm using the unofficial Kisak build of mesa so cannot file a bug for the official version since I have never run that.

        Comment


        • #54
          Originally posted by Leopard View Post

          It doesn't happen. It was fixed long ago.

          Problem is; when devs doesn't test their game on RADV such issues are inevitable. Fwiw Metro Exodus fix came fast and works fine since this commit.

          https://gitlab.freedesktop.org/mesa/...8932ab57ad81dc
          no that only fixed one problem. Much much later in the game at The Caspian chapter I experienced constant crashes with radv, and also in Sam's Story there where constant crash with radv after the first fist fight when you where being transported by boat to the sub.

          Comment


          • #55
            Originally posted by F.Ultra View Post

            no that only fixed one problem. Much much later in the game at The Caspian chapter I experienced constant crashes with radv, and also in Sam's Story there where constant crash with radv after the first fist fight when you where being transported by boat to the sub.
            Please note Kisak build is a build of mesa, there is no such thing as an official Mesa build, you either use your distro default or an external source like a ppa/AUR/etc. but unless whatever Mesa source you are using(distro or external) explicitly ask you not to report bugs to mesa(mostly because those build may contain extra patches) it is 100% perfectly fine to report bugs in Mesa.

            If you are having issues make bug report here https://gitlab.freedesktop.org/mesa/mesa/-/issues

            Comment


            • #56
              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.
              For me it was happening as soon as plasmashell started, but Plasma/kwin uses OpenGL so that would be why it gets triggered. I tried yesterday and it still happened but maybe I had a slightly older build. You're right, it is off-topic. I saw this thread about latest Mesa drivers but forgot LLVM isn't actually used by RADV any more (thankfully).

              Originally posted by jrch2k8 View Post

              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
              I'm on Manjaro, using timeshift so able to roll-back easily or revert individual packages if I have the time to spare. I don't normally see an easy to reproduce bug like this last more than a few days but I couldn't find a bug report for this one, though there are other bugs that mention the "Waiting for fences timed out" error I'm seeing.

              Comment


              • #57
                Originally posted by ResponseWriter View Post

                For me it was happening as soon as plasmashell started, but Plasma/kwin uses OpenGL so that would be why it gets triggered. I tried yesterday and it still happened but maybe I had a slightly older build. You're right, it is off-topic. I saw this thread about latest Mesa drivers but forgot LLVM isn't actually used by RADV any more (thankfully).



                I'm on Manjaro, using timeshift so able to roll-back easily or revert individual packages if I have the time to spare. I don't normally see an easy to reproduce bug like this last more than a few days but I couldn't find a bug report for this one, though there are other bugs that mention the "Waiting for fences timed out" error I'm seeing.
                Yeah, LLVM git is extremely unstable to the point if you build it yourself 5 times a day you can have 4 or 5 broken builds all with different errors, so don't feel too bad about it, just use this repo and have this fast cheat sheath to rollback when you hit the lottery.

                Also a good way if you know how to use PKGBUILD is to manually compile mesa-git but using Manjaro's LLVM release package instead of GIT, usually works really well and fails lot less but may affect performance a bit(but rarely unless you are using a very new GPU)

                Repos:
                [mesa-git]
                SigLevel = Never
                Server = http://pkgbuild.com/~lcarlier/$repo/$arch
                or

                https://aur.chaotic.cx/

                Easy llvm rollback

                cd /var/cache/pacman/pkg
                sudo pacman -U *previous llvm version*.zst

                If you develop C/C++ and you want to use clang-git, be sure your IDE have GCC build option configured and always verify thing fail on both before starting touching your code, trust me i've learned the hard way.

                P.D: Before all the 3000 comments about how this is impossible because rust and OMG this and that, even tho i hate with a passion how LLVM git is handled at least their releases seems quite stable, so this is about bleeding edge LLVM not releases so please avoid the stupid comment "but LLVM 12 works fine for me"

                Comment


                • #58
                  I've found some graphical corruption issues with RADV in some games and had to use AMDVLK ICD.

                  While performance can be great there are still some issues under the hood with radv. (some can be solved with debug flags such as geom and ddc one, I forgot full names)

                  Comment


                  • #59
                    These results are entering Internet Explorer and fglrx territory for AMD's driver, though I will give them the benefit of the doubt and assume this is some kind of temporary regression rather than the normal state of their driver.

                    Even then, it's clear AMD cares so little about it that they don't test even the common stuff that Michael runs in every single review here, which isn't a good look. Or they did and were fine releasing it in this state, which is even worse.

                    Looking on the bright side of things, at least the driver is useful as a bit of hardware documentation that the good drivers can look at to confirm things. Even there AMD is sadly behind by hiding their RT code in the proprietary driver, but at least the rest is available.

                    Comment


                    • #60
                      Originally posted by tomas View Post
                      For some unknown reason Google choose AMDVLK even though RADV would have been superior for Stadia.
                      Wow. If you really think it's an "unknown" reason, you've never worked in this industry. Or any industry, for that matter.

                      Do you imagine that if - ie when - something goes wrong with a game on Stadia because of a driver problem, Google will pull the game, file a ticket on GitHub, and just sit back and jerk off for a few weeks while the bug gets looked at, fixed, and eventually rolled out into a new release the following quarter?

                      Or would they prefer to, yknow, fire off an email to whoever's in charge of RTG these days, remind them just how much $MM Google is paying for all these machines, and "you'd better fix this bug (or more likely, "hack around this defective use of the API" :P) by tomorrow or else..."

                      It's fine to be idealistic - good to be, even - but regardless of how much better you think RADV is, or how stupid you think Google is, the real world and your imaginary world are very much not the same.

                      Comment

                      Working...
                      X