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) by Wootery on Thursday December 21 2017, @02:12PM (5 children)
Does Linux promise API compatibility between minor releases?
(Score: 4, Insightful) by Runaway1956 on Thursday December 21 2017, @03:23PM
I think that they work really really hard toward that goal - but it's not exactly a "promise". When you upgrade, you may expect problems now and then. If you're using the latest and greatest, you may expect problems more often than people who restrict themselves to stable. Since I'm on the testing branch of Debian, I experience issues relatively frequently. On the other hand, if you're still using kernel 3.2 on some distro that was released five years ago, you won't have very many problems. Of course, you are facing obselesence issues, eventually.
For amusement, you might consider this: Automotive technology is around 100 years old now. And, despite that 100 years history, sometimes, the manufacturers create lemons. Linux, Windows, Mac, Gentoo - they all have their lemonade specials. Unlike the automotive industry, software doesn't make guarantees, and it's unlikely that any court will take your side if you should sue. Stuff happens, and eventually, some combination of circumstances will bite you in the ass.
(Score: 2) by LoRdTAW on Thursday December 21 2017, @03:39PM (1 child)
The "stable kernel API/ABI" argument has been an issue for a while. Proponents say it will solve all of our hardware problems while opponents say it will allow hardware manufactured to slip in more binary blobs. Both arguments are valid but the latter means drivers can be neglected and left to rot while Windows drivers are carefully tweaked and optimized.
(Score: 2) by Wootery on Thursday December 21 2017, @03:55PM
Surely it's less evil for a blob to be left to rot, than for it to be periodically unearthed and lazily hacked into just about coping with the API changes, no?
(Score: 0) by Anonymous Coward on Friday December 22 2017, @08:49AM (1 child)
API, yes between minor versions, mostly between major versions. However, this is not handled by the Linux people, the API is controlled by the Glibc people.
ABI, yes, even between major versions ("we don't break user space").
However, this doesn't matter as aside from certain USB stuff, drivers need kernel internals, and internals are NEVER guaranteed to stay the same.
(Score: 2) by Wootery on Friday December 22 2017, @09:20AM
I meant the API and ABI for kernel modules.