Announcement

Collapse
No announcement yet.

Mesa RADV vs. AMDVLK Radeon Vulkan Performance For July 2021

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

  • theriddick
    replied
    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)

    Leave a comment:


  • jrch2k8
    replied
    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

    Helping you, so you don't have to worry about building AUR packages each update!


    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"

    Leave a comment:


  • ResponseWriter
    replied
    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.

    Leave a comment:


  • jrch2k8
    replied
    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

    Leave a comment:


  • F.Ultra
    replied
    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.

    Leave a comment:


  • F.Ultra
    replied
    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.

    Leave a comment:


  • Leopard
    replied
    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.

    Gotta track those sets too to free them. Alse changed the search on destroy to check for set instead of offset since offset is not necessarily unique anymore. Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/4652...

    Leave a comment:


  • QuImUfu
    replied
    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.

    Leave a comment:


  • jrch2k8
    replied
    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

    Leave a comment:


  • jrch2k8
    replied
    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.

    Leave a comment:

Working...
X