AMD's Open-Source Strategy Is Now Ten Years Old

Written by Michael Larabel in Display Drivers on 30 October 2017. Page 1 of 1. 42 Comments

What an incredible ride it's been over the past ten years of AMD pursuing an open-source Linux graphics driver strategy.

It was back in September of 2007 when I exclusively broke the news about the new ATI/AMD open-source driver strategy. I hadn't done a "decade recap/redux" yet as it's hard to pinpoint an exact date to celebrate: that article was on 6 September 2007, it was in November when the HD 2900XT (the flagship GPU at the time) started working with the RadeonHD mode-setting driver, some days later the flow of GPU hardware documentation began publicly, much longer before 3D started coming together, or it was originally in the summer of 2007 when SUSE engineers submitted the original AMD open-source proposal to the company and ultimately began developing the RadeonHD driver stack. Whatever way you want to dice it, we're now through ten years of this AMD open-source driver effort that has only gotten better over the years.

Ten years ago their open-source driver effort began in order to provide a full-featured open-source driver stack for the R500/R600 graphics cards, that "RadeonHD" effort continued on for several years, xf86-video-ati ultimately picked up DDX responsibilities for these newer GPUs, the R600 Gallium3D driver matured over the years that followed, and most of you know the story well if you have been following Phoronix over this time with our often exclusive reporting on the Radeon Linux graphics driver progress and performance.

It was once celebrated to simply get a working open-source X.Org driver to work, let alone 3D.

The real milestone one could argue is when a few years back AMD pursued their new driver approach they are using today with the hybrid AMDGPU-PRO and the "pure" open-source driver stack, as detailed back in 2014 in another exclusive: AMD Is Exploring A Very Interesting, More-Open Linux Driver Strategy. Since then their AMDGPU kernel driver has got increasingly better thanks to less duplicated efforts with abandoning their fglrx Linux kernel module in favor of upstream AMDGPU, RadeonSI has got immensely better for OpenGL on Linux, and all around users seem much happier with the open-source Linux Radeon driver stack being the preferred approach by Linux gamers and AMDGPU-PRO mostly being left to workstation customers.

It's really been over the past two years that the AMDGPU+RadeonSI driver stack has become viable for Linux gaming and then over 2017 where the driver's performance is finally competing with the proprietary NVIDIA Linux graphics driver. In fact, the open-source driver code now outperforming AMDGPU-PRO OpenGL with AMD's long-standing proprietary OpenGL driver. Most of the same functionality offered by AMDGPU-PRO is available via the fully open-source driver, sans currently OpenGL compatibility profiles that is a big requirement for workstation customers, but there's some recent work in that direction. If that's solved upstream and the open-source Vulkan driver situation cleared up as well as getting the ROCm OpenCL bits sorted out, it will be interesting to see in the future if AMD will decide to focus solely on their open driver stack for future deployments rather than AMDGPU-PRO.

There was also lots of controversy in the early days over AtomBIOS as well as open-sourcing milestones like getting a video BIOS disassembler working in their efforts.

It hasn't been all rosy though over the past decade. There was the drama many years ago of xf86-video-radeon vs. xf86-video-ati and SUSE developers ultimately parting ways with AMD's open-source efforts, delivering some features has taken more time than customers and gamers would have liked, and not everything going quite as planned. One recent example of things not going quite as planned is the length of time for getting the AMDGPU DC display code (or originally known as AMDGPU DAL) into the mainline kernel for delivering HDMI / DP audio, atomic mode-setting, and more to the mainline kernel. This has also been while Radeon RX Vega graphics cards don't have out-of-the-box display support currently with the upstream Linux graphics stack. Fortunately, AMDGPU DC should be mainlined for the Linux 4.15 kernel as long as Linus Torvalds has no objections.

Other areas still looking to be improved upon by the open-source AMD Linux driver effort and possible 2018 action items include:

- The open-source Vulkan driver situation. Since before the Vulkan 1.0 announcement, AMD had briefed me on plans to likely open-source their Vulkan driver within six months or so. It's now going on almost two years without their Vulkan driver code. But in this time the RADV Vulkan driver has come about, it's now Vulkan 1.0 conformant, and is performing quite well considering the limited manpower and development largely driven by the community. It remains to be seen if/when the AMD Vulkan driver will be officially open-sourced and how the Radeon Vulkan driver ecosystem will proceed from there with that driver not being part of Mesa, RADV developers having expressed plans to still continue their effort regardless of AMD putting out their code, etc.

- There's still no "control center" / GUI control panel for the AMDGPU-based driver stack on Linux. AMD representatives previously communicated with me about potentially open-sourcing Catalyst Control Center / Radeon Software Settings, but that's been about two years with no activity to report today. In that time though they have exposed more ioctls and other interfaces needed for a GUI control panel to read temperatures, performance metrics, and various tunables for making the GUI settings area useful. But as it stands today there is nothing viable for Radeon Linux gamers and no word when that might change.

- AMD has been pursuing "ROCm OpenCL" for their next-generation OpenCL driver that is open-source, leverages LLVM Clang, and is shaping up quite well. While the components are open-source, not everything is upstream yet for Clang or the Linux kernel. As a result, it's not trivial to deploy the ROCm OpenCL driver yet across non-enterprise Linux distributions. This will hopefully be a matter of the past in 2018 when the needed prerequisites are mainlined, but just a pity it's taken so long for getting viable open-source Radeon OpenCL support.

But all in all, it's been a heck of a time over the past ten years seeing the continued evolution of open-source AMD. This year has been very remarkable alone with all the RadeonSI performance improvements, RADV really becoming viable for Vulkan Linux gaming, AMDGPU DC about to hit mainline Git, support for Steam VR on mainline, OpenGL 4.5 completion and nearly OpenGL 4.6, and many other advancements made. It was just with the Radeon RX Vega launch where they delivered fantastic open-source support at launch (sans the DC situation) and has only gotten better since its debut.

What's been your favorite of the open-source AMD efforts over the past decade? What do you hope to see out of the AMD Linux drivers in 2018? Share your thoughts with us in the forums. I will be having a few special articles coming up shortly looking at the historical AMD Linux graphics performance, a larger Radeon GPU comparison with the latest open-source code, etc. If you have enjoyed all of our benchmarks and often exclusive coverage over the past 13 years on Linux hardware topics, consider showing your support by joining Phoronix Premium.

If you enjoyed this article consider joining Phoronix Premium to view this site ad-free, multi-page articles on a single page, and other benefits. PayPal or Stripe tips are also graciously accepted. Thanks for your support.

Related Articles
About The Author
Michael Larabel

Michael Larabel is the principal author of and founded the site in 2004 with a focus on enriching the Linux hardware experience. Michael has written more than 20,000 articles covering the state of Linux hardware support, Linux performance, graphics drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and automated benchmarking software. He can be followed via Twitter, LinkedIn, or contacted via