AMD Open Source Driver for Vulkan project is discontinued

2025-09-170:3115467github.com

In a move to streamline development and strengthen our commitment to the open-source community, AMD is unifying its Linux Vulkan driver strategy and has decided to discontinue the AMDVLK open-sourc...

You can’t perform that action at this time.


Read the original article

Comments

  • By greatgib 2025-09-177:422 reply

       AMD is unifying its Linux Vulkan driver strategy and has decided to discontinue the AMDVLK open-source project, throwing our full support behind the RADV driver as the officially supported open-source Vulkan driver for Radeon™ graphics adapters.
    
    Scary title but good news in the end I think.

    • By willvarfar 2025-09-177:583 reply

      What level of support will they give RADV? Or is it just that AMD ultimately do less?

      • By account42 2025-09-178:302 reply

        They have done pretty well with the open source OpenGL drivers that were also initially developed outside AMD.

        AMDVLK was always a weird regression in the openness of the development model compared to that. Maybe understandable that the bean counters wanted to share the effort between the Windows and AMD drivers but throwing away the community aspect in order to achieve that made that approach doomed from the start IMO. The initial release being incredibly late (even though Vulkan was modeled after AMD's own Mantle) was the cherry on top that allowed RADV to secure the winning seat but probably only accelerated the inevitable.

        • By pjmlp 2025-09-1711:472 reply

          So well that my Asus Netbook went from OpenGL 4.1 down to OpenGL 3.3, and when it finally got OpenGL 4.1 back, several years later, it died a couple of months later.

          • By account42 2025-09-1712:081 reply

            Yes exactly, they (or someone else) did eventually add OpenGL 4.1 support for your GPU to the open source drivers which never had it before.

            That you were "forced" to switch away from the old proprietary driver for some reason does not negatively implicated AMD's contribution to the open source drivers.

            • By pjmlp 2025-09-1712:141 reply

              The reason being the old proprietary driver were dropped from Linux distros without feature parity, and given how great Linux drivers work across kernel versions, everyone got a downgraded experience for several years.

              • By bigyabai 2025-09-1717:141 reply

                ...and you're telling us it's Linux' fault that you didn't want to pin the package?

                • By michaelmrose 2025-09-1717:54

                  Over a period of years people get new machines, upgrade existing machines to new distro versions, and update other packages in a way that is oft incompatible with keeping an older package pinned as its requirements may become incompatible with the requirements of newer packages, kernels, and of course distro versions.

                  I think they are blaming the vendor who received their money not the nebulous and non-specific Linux community.

                  Despite being lauded compared to closed source Nvidia AMD has had painful support issues as well.

        • By tonyhart7 2025-09-179:192 reply

          why we have 2 project anyway??? what is the history???

          I thought mesa is always default since I use fedora kde

          • By account42 2025-09-1710:171 reply

            AMD developed their closed source Vulkan driver for Windows based on their proprietary shader compiler from their existing proprietary OpenGL driver (amdgpu-pro). They promised to release this driver as open source but didn't want to release the shader compiler for who knows what reason so this took them a while. Meanwhile David Airlie (Red Hat) and Bas Nieuwenhuizen (student at the time) didn't want to wait for that or were just looking for a challenge and wrote their own open source Vulkan driver (radv) which got pretty good results from the start. Linux distributions prefer open source drivers so this one quickly became the default. One AMD released the open-source version of their driver (amdvlk) it was faster than radv in some games but not decidedly so. It was also not an open project but rather just an open source release of their proprietary driver with a different shader compiler. So there wasn't really any reason for the open source developers to abandon their work on radv and switch to amdvlk. But they could and did use amdvlk to learn from it and improve radv so it was still useful. When Valve decided to contribute directly to Linux graphics drivers, radv was already winning so they backed that one as well.

            Note that this is only about the user-space portion of the driver - the kernel part of the Linux drivers is shared by all of these as well as the OpenGL drivers - there used to be a proprietary kernel driver from AMD as well but that was abandoned with the switch to the "amdgpu-pro" package.

          • By giancarlostoro 2025-09-1713:481 reply

            Idk but MESA never worked for me, ever. Any time I installed a distro to try, if MESA was running, I basically had a non-functioning desktop. I think part of it may have been Wayland related, which is frustrating, but these days its gotten drastically better.

            • By tankenmate 2025-09-1715:20

              What hardware are you running?

      • By arghwhat 2025-09-178:30

        They already work on radv, which is already the better vulkan driver.

        This is a matter of AMD no longer wasting time on a pointless duplicate project no-one is really interested in. They can allocate more resources for amdgpu and radv and ultimately do less overall by getting rid of the redundant project.

        Win-win.

      • By greatgib 2025-09-1717:58

        I think that the customer base of AMD cpu and GPU is exploding thanks to their goodwill to work and provide what is needed for linux and open source drivers, so I don't see why they would reduce their effort when it so easily yield so much positive effect for them.

        Almost no one is scared anymore to buy AMD for linux desktop and servers knowing that it normally works well and the same kind of person will be the one doing recommendation for their families and relatives or relative companies even if these one are using windows.

    • By sylware 2025-09-1710:281 reply

      It is dangerous for RADV which already has its own issues. And when you look at AMDVLK, you don't want those devs anywhere near RADV.

      • By vrighter 2025-09-2016:502 reply

        could you elaborate on those issues? genuinely curious

        • By sylware 2025-09-2220:08

          BTW, some forgot one of the C preprocessor features was to handle simple namespaces (for "One-Compilation-Unit"). That to avoid symbol colision. Some will say it is really painful to deal with, and I can tell those are liers since I did it: in reality you have very rarely symbol colisions, namely you can code without thinking about it, only to tag the public identifiers with a comment to deal with it once the code settled down.

        • By sylware 2025-09-2112:18

          [dead]

  • By CBLT 2025-09-173:14

    https://www.phoronix.com/news/AMDVLK-Discontinued

    > This is a good but long overdue decision by AMD. RADV has long been more popular with gamers/enthusiasts on Linux than their own official driver. Thanks to Valve, Google, Red Hat, and others, RADV has evolved very nicely.

  • By andy_ppp 2025-09-1710:244 reply

    I always think just open sourcing the whole software stack for graphics cards would be an excellent thing for hardware manufacturers, in the end these are free pieces of software and I've certain there would be a big community contributing loads of cool things for free. AMD (say) would also sell a load more hardware as enthusiast features would be added by the community.

    Maybe I'm just naive but the downsides of doing this seem absolutely minimal and the upsides quite large.

    • By Symmetry 2025-09-1714:13

      Those are essentially the reasons that Intel has always(?) had open source GPU drivers and AMD has been supporting open source since around 2009. As a result I think most people would recommend AMD cards for people interested in gaming on Linux, the experience can be a lot smoother than using NVidia's closed source drivers.

    • By ChocolateGod 2025-09-1713:541 reply

      That's easier said than done, AMD and Nvidia probably have licensed and patented code etc in their closed-source drivers, which would make it difficult to open source, where as a project open source from the get go won't have these issues.

      Nvidia got around this on their kernel driver by moving most of it to the cards firmware.

    • By giancarlostoro 2025-09-1713:502 reply

      I still do not understand why they don't it makes their hardware basically good for life, since now you can run it on any OS if you really want to put the effort in to wire it all up.

      • By dcan 2025-09-1713:561 reply

        Patents and licensing, usually

        https://news.ycombinator.com/item?id=39543291

        • By giancarlostoro 2025-09-1714:20

          Ah so HDMI is one part of it, that's really unfortunate. Thank you for this insight.

      • By andy_ppp 2025-09-1717:32

        It's tragic that the patent system, that is meant to make sharing IP better, actually is used to extract rents from the everyone... Software patents much like maths should clearly be illegal.

    • By fidotron 2025-09-1714:201 reply

      > I always think just open sourcing the whole software stack for graphics cards would be an excellent thing for hardware manufacturers,

      > Maybe I'm just naive

      Yep.

      There are things hidden in the design of very widely used hardware that would make people's heads explode from how out there they are. They are trade secrets, and used to maintain a moat in which people can make money. (As opposed to patents which require publishing publicly).

      If you live in open source land you cannot make money from selling software. If there is no special sauce in the hardware you won't be able to make money from that either. Then we can all act surprised that the entire tech landscape is taken over by ads and fails to meaningfully advance.

      • By yencabulator 2025-09-1716:161 reply

        Yes clearly that's why the from-scratch RADV driver was often faster.

        The dirty open secret in the tech industry is that the special sauce almost always just isn't all that special.

        • By fidotron 2025-09-1716:281 reply

          > Yes clearly that's why the from-scratch RADV driver was often faster.

          Because AMD didn't actually care about the Linux driver since it didn't make them moeny.

          > The dirty open secret in the tech industry is that the special sauce almost always just isn't all that special.

          Only among people where that's true. In the computer industry just look at the M series of chips where it's very clear that their direct competitors can't establish why it does what it does.

          • By yencabulator 2025-09-1716:341 reply

            > can't establish why it does what it does

            This is weird Apple fanboy head-in-the-sand thinking. The Mx chips have been dug into plenty and are just good engineering, not magic. AMD's horribly-named "Ryzen AI Max+ 395" chip is definitely moving in the same direction.

            • By fidotron 2025-09-1716:381 reply

              Right, so we have other ARM64 implementation that are this good?

              Bonus points for ones without ex-Apple employees involved in their design, because maybe those people might know something about it.

              • By michaelmrose 2025-09-1718:271 reply

                Qualcomm Snapdragon X Elite. Qualcomm has been making ARM chips prior to Apple. Admittedly its 4nm vs 3nm for the M4.

                • By fidotron 2025-09-1719:26

                  Those did involve ex-Apple people, and there isn't proof that they are quite as good either, but they are the closest that anyone has publicly come.

                  Qualcomm have never actually caught up with Apple performance wise since the introduction of Arm64. They had a very nice 32 bit implementation and were completely caught off guard. Prior to their NuVia acquisition their 64 bit efforts were barely improvements on what you can just license from Arm directly, to the point for a while that is all they were.

HackerNews