Announcement

Collapse
No announcement yet.

AMDVLK 2021.Q2.1 Finally Adds Navi 12 Support

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

  • #21
    Originally posted by SkyWarrior View Post
    Aside from ray tracing and other mambo jambo AMDVLK should get its hands off of our precious RADV.



    I will be uninstalling AMDVLK until this shit is cleaned up from its so called requirements. Before switchable graphics we were able to use any vulkan driver by just changing VK_ICD_FILENAMES variable. Now AMDVLK takes over and GPU0 becomes llvmpipe instead of RADV.
    It's easier now....instead of
    Code:
    VK_ICD_FILENAMES=wtf was that, I gotta go ls /etc first
    you just use
    Code:
    AMD_VULKAN_ICD=AMDVLK or RADV
    To me, that's a lot easier and all you have to do is add one line to your bashrc or any other env loader file and forget about it just like before. Need to switch on the fly? AMDVLK and RADV are much easier to remember than a path + a filename.

    Comment


    • #22
      Well it may look like it however as it masks RADV now the GPU0 becomes llvmpipe and if you are using desktop apps using vulkan such as libreoffice google skia etc your apps will start suffering. I removed those json files from the /etc/vulkan/implicit.icd.d folder and now RADV is not masked at all by AMDVLK and apps will choose GPU0 RADV as my hardware accelerated default option.

      Heck AMDVLK developers are also aware that skia performance is not good enough.

      Comment


      • #23
        Originally posted by skeevy420 View Post

        That's more of an AMD and Intel problem. When you push your drivers and/or fixes to upstream, users have to be rolling along with upstream to get those fixes. You have to be on Ubuntu with HWE, an AMDGPU-Pro supported distribution, or a rolling release distribution. Stray from that and you'll likely have a bad time with new hardware from anyone but Nvidia.

        With Nvidia it's the other way around. You're libel to roll right on by what Nvidia supports if you're not paying attention. With them there are times where you'll have to wait on them to update their driver before you can start updating things again.
        The point is, not every distribution uses rolling release for obvious reasons. The alternative i.e. what NVidia does on Linux (to a lesser extent) and what AMD/NVidia do on Windows is that its the manufacturers problem which is where the responsibility should lie, their drivers are separated from the kernel so as long as you are running a somewhat recent version of the kernel in question, you just need to get the latest driver from their site (and they make sure the drivers are available well before the graphics cards can be bought from retail channels).
        Last edited by mdedetrich; 08 April 2021, 04:26 PM.

        Comment


        • #24
          Originally posted by mdedetrich View Post

          The point is, not every distribution uses rolling release for obvious reasons. The alternative i.e. what NVidia does on Linux (to a lesser extend) and what AMD/NVidia do on Windows is that its the manufacturers problem which is where the responsibility should lie, their drivers are separated from the kernel so as long as you are running a somewhat recent version of the kernel in question, you just need to get the latest driver from their site (and they make sure the drivers are available well before the graphics cards can be bought from retail channels).
          Or more distributions can do what Ubuntu HWE and Windows do and try to separate user-space and the kernel. Keep the kernel and drivers up-to-date while keeping user-space LTS and only introducing new things when the user upgrades to the newer version. To me that seems more practical than the RHEL and SLE methods of applying thousands of patches to an LTS or old kernel to keep it up-to-date while also keeping an LTS user-space and then upgrading everything after some time.

          Comment


          • #25
            Originally posted by skeevy420 View Post

            Or more distributions can do what Ubuntu HWE and Windows do and try to separate user-space and the kernel. Keep the kernel and drivers up-to-date while keeping user-space LTS and only introducing new things when the user upgrades to the newer version. To me that seems more practical than the RHEL and SLE methods of applying thousands of patches to an LTS or old kernel to keep it up-to-date while also keeping an LTS user-space and then upgrading everything after some time.
            GPU drivers cannot completely sit in userspace because of performance reasons (fun fact, in Windows XP graphics drivers sat in userspace and then key got moved to kernel level because of performance reasons).

            What Windows has now is a low level stable kernel API which graphics drivers code against, this is what allows you to use the latest NVidia/AMD graphics driver even if the Windows version is quite old.

            Forcing a kernel strategy amongst all distributions is a fantasy that is never going to happen

            Comment


            • #26
              Originally posted by skeevy420 View Post

              As a 7 year AMD GPU user and self-reported AMD fanboy -- you should learn to expect that. While they try, their day 1 Linux support has never been as good as their day 1 Windows support. It's kind of par for the course for us to get stuff 3 to 6 months later. Come months 8 or 9, however, stern WTFs will start coming from people as lenient and as understanding as myself. If AMD had spectacular day 1 support the driver wouldn't be known as Fine Wine.

              I just saw Join Date 2008. You should already know that.
              Yeah I already know that, but in 2021 I truly expect AMD to improve in this area, so here is my disappointment.

              Comment

              Working...
              X