Announcement

Collapse
No announcement yet.

AMDVLK 2021.Q2.6 Vulkan Driver Released - Removes Pre-Polaris / Pre-Raven Support

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

  • #11
    Originally posted by bple2137 View Post
    I love how Linux has always several fundamentally different libraries for the exact same purpose, so that end users could be more confused. I don't mind having alternatives, but there should be some easy to understand mechanism to control what's being used (other than providing some long environment variables you need to duckduckgo every time).
    This is a problem for many users and can be very frustrating. Just know that it is not done deliberately to confuse people and that more people would be complaining if there wasn't so many options (You can't please all). If we lived in Utopia then we would only have a single OS, but unfortunately that's not the case right now. We at least don't have to compile our own kernel to get 3D rendering anymore.

    Michael puts in a lot of effort to explain things in his articles, in this case he talks about both implementations AMDVLK and RADV which at least covers the basics.

    There are many projects that all have bits of documentation ranging with various levels of detail and difficulty to understand. The basic sites that I have used over the years were: https://www.x.org/wiki/RadeonFeature/ and https://mesamatrix.net/ as for troubleshooting IRC was always the best to get pointed into the right direction when you're feeling lost. Over the past 10+ years I not had the need so I can't say if that's still the best source. There are many new communities now with lots of active members. Most distros also have a newbie section where you can ask questions without someone biting your head off. If you want a single domain with lots of information https://wiki.archlinux.org/ has been the best for me.

    One would think that someone could try to bring in all the documentation from all over the web and put it all in one place, it sure would be wonderful but it would be extremely expensive to maintain. Just like we see with this article. GNU/Linux is changing all the time.

    Comment


    • #12
      Originally posted by bple2137 View Post
      Can somebody explain what's the point of that driver? It never really worked for me on Polaris. Installing it straight up breaks most of games or other apps I use.
      It even got worse with Navi in terms of visual corruption issues etc., and they are ultra-slow with fixes (if they even bother to fix anything). If something doesn't work with RADV, one should just file a bug report. There is a really good chance to get helped, as Mesa devs really care. Unlike "official" AMD and their "official" drivers who just abandon their users over and over again.

      Comment


      • #13
        Originally posted by bple2137 View Post
        I love how Linux has always several fundamentally different libraries for the exact same purpose, so that end users could be more confused. I don't mind having alternatives, but there should be some easy to understand mechanism to control what's being used (other than providing some long environment variables you need to duckduckgo every time).
        It's the distro's job to choose suitable defaults when there are multiple options available. Ideally the distro would also provide an easy way to choose if there are advantages and disadvantages to the different options, but I don't think that applies to AMDVLK anyway. You're better off with RADV.

        Comment


        • #14
          I like to make fun of that little caveats we have in the free software world - in fact that explains really well why commercial platforms won the desktop battle. Anyway, we still remember how bad the fglrx driver was, so not much to complain about these days

          Comment


          • #15
            The situation with AMD GPU'S and linux is way to complicated.

            We have three Vulkandrivers available for our OS. AMD should just adopt MESA RADV like they did with MESA RadeonSi for OpenGL and stop developing AMDVLK. This driver might be the official AMD opensource Vulkandriver but it is not supported by any application or game. It is also inferior in performance compared to MESA RADV and AMDGPU-Pro Vulkan. I never understood why AMD went this route.

            Comment


            • #16
              Thank Finagle for RADV. If things had been left up to AMD, I could have updated my OS in the next month and lost Vulkan support.

              I hope this doesn't portend another push to remove GCN 1.0/1.1 (and now 1.2/1.3) from the AMDGPU kernel driver.

              Comment


              • #17
                We've come a long way from the fglrx era of ATi's software stack, which required people to make the compromise between having official vendor 3D-accelleration at the cost of your desktop crashing 4-5 times a day, or having a stable desktop that didn't crash and had anemic 3D support through free drivers. Both radeonsi and amdgpu (and RADV by association) are robust, stable, and the gold-standard for GPU driver implementations in today's linux systems.

                I don't think the branding is confusing at all; rather, AMD needs to spend a little more effort encouraging only corporate and enterprise users who require vendor-provided drivers for insurance reasons to use the AMDVLK/AMDGPU-Pro offerings, which was the point of the original fglrx (FireGL corporate drivers getting extended for end-user cards), and encouraging users that the free offerings are now of good-enough quality that they are preferred for end-user/consumer gaming usage.

                AMD's higher-ups need to watch as the free driver begins to eclipse their offering, so that they can safely dip their waist in the water after the toe and foot-dipping tests since have sufficiently been proven not to destroy the company, and even encourage sales and consumer interest. I bet the next metric to allow them a full-body-dunk adoption of open driver development practices will be when the free driver's functionality begins attracting developer's away from their internal driver offering (everyone's rooting for ROCm), so AMD can justify offering paid support on mainline kernel/Mesa tree amdgpu drivers.

                Comment


                • #18
                  Originally posted by Teggs View Post
                  Thank Finagle for RADV. If things had been left up to AMD, I could have updated my OS in the next month and lost Vulkan support.

                  I hope this doesn't portend another push to remove GCN 1.0/1.1 (and now 1.2/1.3) from the AMDGPU kernel driver.
                  This is unlikely, as there's no incentive for upstream to remove functionality because a corporation has a vested interest in planned obsolescence. Linux (and Mesa) doesn't work that way. Most free software doesn't.

                  Comment


                  • #19
                    Originally posted by ripper81 View Post
                    The situation with AMD GPU'S and linux is way to complicated.

                    We have three Vulkandrivers available for our OS. AMD should just adopt MESA RADV like they did with MESA RadeonSi for OpenGL and stop developing AMDVLK. This driver might be the official AMD opensource Vulkandriver but it is not supported by any application or game. It is also inferior in performance compared to MESA RADV and AMDGPU-Pro Vulkan. I never understood why AMD went this route.
                    Well, they get AMDVLK and the pro driver (which has only a few differences) for free because they have to write Windows drivers, so why not?

                    Comment


                    • #20
                      Originally posted by Aryma View Post
                      so next few years they will kill RX 500 series too ?
                      i was planning to buy rx580 or 400 series look like i need to buy a GPU with some pricing for a car in the middle of Africa to display something with my CPU without igpu


                      Originally posted by skeevy420 View Post

                      I hope not. I had to dip into my new GPU funds for more storage yesterday in anticipation for Win11. Win10 is on a 15 year old 2TB HDD that is starting to give SMART warnings so it jumped to the top of the "upgrade me" list.

                      Got 5TB for $202. A 1TB NVME for the OS and a 4TB HDD for storage. I think Amazon messed up on the HDD's price and me buying it alerted them to it. Literally the second after I bought it the price jumped from $94 to $131. I'll finally have all my operating systems on SSD or better so I'm happy.

                      4TB for $104 after tax

                      It might be the Dark Ages for GPUs but it sure is the Golden Ages for Storage.
                      they are not removing the driver or mesa. as the driver and mesa are open source, separate projects from amd. the linux kernel still supports cards that go back to the ati 9800. which amd dropped support a decade ago. cards like the ati hd 6950 are still supported in the kernel and by mesa. and amd dropped support for terascale cards back in 2015. they don't have support in windows anymore, and amd themselves don't contribute official support for them in linux, but they sure still have support here on linux thanks to the kernel devs and mesa.

                      amdvlk is amd's open source release of their vulkan stuff for linux. all it means is amd will no longer provide support themselves for those generations of cards in amdvlk. it doesn't stop the community nor does it stop projects like mesa.

                      there will come a time where amd will drop complete support of gcn but that doesn't mean its death here on linux. on linux, support will live on long past amd officially ends support themselves for them.

                      when it comes to amdvlk, well you don't have to use it. personally, i have a 6900xt and i don't even have amdvlk installed. i just run pure mesa.
                      Last edited by middy; 26 June 2021, 01:38 AM.

                      Comment

                      Working...
                      X