SoylentNews is people
SoylentNews
After a long wait, AMD is finally delivering on their two-year promise of open-sourcing their AMD Vulkan driver for Linux!
Ahead of the Vulkan 1.0 debut nearly two years ago, we heard that for AMD's Vulkan Linux driver it was initially going to be closed-source and would then be open-sourced once ready. At the time it sounded like something that would be opened up six months or so, but finally that milestone is being reached! Ahead of Christmas, AMD is publishing the source code to their official Vulkan Linux driver.
What Is This Driver?
This Vulkan driver they are open-sourcing is their "official" Vulkan driver as found for Linux users already within the AMDGPU-PRO driver. It's also the shared code-base to their Vulkan Windows driver. Basically, it's their full-featured Vulkan driver that AMD has been investing in the past 2+ years.
With this being the official AMD Vulkan driver and from their shared code-base, it's important to note that this is NOT a driver living within Mesa. This AMD Vulkan driver lives in its own code-base and is not using or dependent upon Mesa/Gallium3D but rather just interfacing with libdrm / AMDGPU DRM / LLVM directly.
... With this official Vulkan driver being shared across platforms, I was curious if this open-source access would allow it to be built on Microsoft Windows or if they are not opening up all of the bits for the Windows integration, etc. The AMD response to this question was, no, the code they are pushing out was stripped down to just their Linux code.
What About RADV?
... RADV was started out by David Airlie and Bas Nieuwenhuizen in what they figured would be a short-lived effort while waiting on the AMD open-sourcing milestone to occur. But with this AMD milestone having taken much longer than anticipated, in the mean time RADV has become a roughly feature complete and compliant Vulkan driver with modest performance potential. David Airlie has indicated in our forums that RADV is mature enough now where he doesn't plan to stop work on this driver when the AMD open-sourcing of their driver happens. Thus moving forward we're likely to see these two separate open-source Radeon Vulkan drivers continue.
At least with the official Vulkan driver not being Mesa-based, it isn't "stepping on the toes" of RADV or anything as it will continue to be its own separate code-base while RADV continues to live within Mesa.
Only time will tell what will happen in the future if RADV developers will lose interest and stop maintaining the driver or if Linux gamers will continue preferring RADV since its already packaged and available on many Linux distributions, etc.
It is worth noting that AMD is only opening the parts of their proprietary driver that are related to Vulkan; the OpenGL components are remaining closed-source.
With two competing open-source drivers now available (AMD's AMDGPU and Mesa's RADV), will this mean the end of one of them going forward or will both continue to live on independently? Does having two choices merely further fragment the Linux ecosystem, or is it good to be able to switch between drivers where one may be lacking in performance or compatibility with certain software and games?
Further reading:
- AMDGPU-PRO 17.50 Now Bundles Open-Source Components, Lets You Mix & Match Drivers
- The Feature Differences Now Between AMD's Two OpenGL & Two Vulkan Linux Drivers
- AMDGPU-PRO 17.50 vs. RADV/RadeonSI Radeon Linux Gaming Performance
(Score: 2, Informative) by djh2400 on Thursday December 21 2017, @02:38PM (2 children)
My understanding is that AMD feels they must maintain their own driver in order to support enterprise/business customers. They can't just leave a complex video driver for a flagship line of products up to the whims of the Mesa team, which may or may not break things at new versions or perhaps may or may not accept pull requests from AMD themselves. In order to provide support for their product (graphics cards under Linux), they need something that they fully control. (Although, why would they be picky about control on the graphics side while happily letting the Linux team control the built-in Vega drivers?)
Furthermore, I believe that, to them, the idea of adopting RADV from Mesa directly — even with the ability to add their own, custom patches — ultimately would create more work for them since their in-house driver is part of and shares many similarities to the Windows driver. Maintaining two distinctly code bases is likely something they feel would cost too much or that they can't handle effectively.
Of course, Mesa is now free to peruse AMD's code and copy over any missing features, just as AMD is now capable of from Mesa. My guess is that neither party feels they can leave the graphics-driver project entirely up to the other, and so both drivers will probably live on for now. I expect that regular users will be happy sticking with Mesa while business customers will stick to a driver which is "officially supported" (although RADV outperforms AMDGPU in certain benchmarks already). Though, I admit my understanding of the underlying issues and/or politics is probably limited, so take all of this with a grain of salt. I'd love to be corrected if someone knows more!
(Score: 2, Informative) by djh2400 on Thursday December 21 2017, @02:41PM
My apologies; I meant Ryzen drivers. I was intending to contrast how the graphics line is managed from their perspective compared to the processor line.
(Score: 3, Informative) by Wootery on Thursday December 21 2017, @03:06PM
For OpenGL, we'll still need Mesa. AMD have only Freed their Vulkan driver.