1. Computers
  2. Display Drivers
  3. Graphics Cards
  4. Memory
  5. Motherboards
  6. Processors
  7. Software
  8. Storage
  9. Operating Systems


Facebook RSS Twitter Twitter Google Plus


Phoronix Test Suite

OpenBenchmarking Benchmarking Platform
Phoromatic Test Orchestration

AMD Is Exploring A Very Interesting, More-Open Linux Driver Strategy

Michael Larabel

Published on 22 March 2014
Written by Michael Larabel
Page 1 of 3 - 158 Comments

This week I was out at the Game Developer's Conference not with a focus on games but to learn about some changes they AMD currently pursuing for their Linux driver model. If this new Linux driver model goes through, the Catalyst Linux driver will be more open, but it's not without some risk. Read more in this Phoronix exclusive story.

On Thursday and Friday of this week I was at GDC 2014 with a primary focus of learning more about what AMD's doing to improve their Linux driver support in an age where more games are being ported to Linux, there's Linux-based "Steam Machines" PC game consoles coming to the market, and an overall increase in consumer Linux interest. The short answer of what AMD's trying to do is seeing about leveraging the existing (with modifications) open-source Radeon (Direct Rendering Manager) kernel driver underneath the closed-source Catalyst driver. The end result for the Catalyst Linux driver would come down to primarily being a user-space binary module without the need for the existing closed-source kernel driver portion. The fully open-source Radeon Linux graphics driver stack would remain for those wanting to use the Gallium3D drivers in place of Catalyst and there would be greater collaboration around the Radeon kernel support given there will just be one kernel driver.

What AMD's seeking to do by changing up their high-performance Linux driver is having a completely free kernel driver that's relied upon by Catalyst and would live within the mainline Linux kernel in order to ease support for Linux consumers. When installing the AMD Catalyst driver (or NVIDIA's binary driver) right now a full compiler stack is needed on the system in order to compile the "shim" code sitting between the Linux kernel interfaces and the binary kernel driver. The compiler support is needed locally due to the many different Linux kernel versions out there without having a stable Linux kernel API/ABI. Additionally, there's some legal restrictions in being able to easily redistribute compiled non-open-source kernel modules that link against the kernel. If the Catalyst closed-source driver was isolated to user-space, there wouldn't be these issues with regard to Linux kernel fragmentation, having the need for a compiler to be present on the local system, and there wouldn't be any incompatibility issues with new Linux kernel releases. As the Catalyst driver stands now, it can be several weeks to months after a major stable kernel release before there's an official Catalyst update that properly supports new Linux kernel releases for API/ABI compatibility.

Having only one Linux kernel driver for both the Mesa/Gallium3D and Catalyst drivers would in the end also lead to more centralized collaboration and improvements on the driver, less code duplication, and overall a more open-source driver. The user-space Catalyst code would remain closed-source with no indications of that code being opened up, at least not in the foreseeable future. New hardware enablement, features, and other improvements should land much faster too then in the Radeon Direct Rendering Manager kernel driver should there only be this one kernel driver. This approach would also lead to Wayland/Mir support on Catalyst with using the Radeon KMS driver, as long as the Catalyst user-space then exposed the necessary EGL extensions.

While this new strategy sounds really great on the surface, it has yet to be proven and there's no guarantee yet by AMD developers that they will be able to pull off this feat. In fact, upon hearing about this proposal I immediately had reservations about whether this approach would be technically possible without major changes to both the open and closed-source drivers and whether this work will be accepted to the mainline Linux kernel. While a novel approach and AMD should be applauded for their continued open-source/Linux friendliness, it's probably unlikely that - everything - will pan out as currently planned. It's also not clear whether the existing DRM driver will be used or a new kernel driver written or large modifications to the existing open-source code-base. AMD's Graham Sellers had said, "Whatever happens, we’re hoping that the open source components of both driver stacks (Catalyst and open source) are one and treated as a first-class citizen."

Besides the OpenGL driver being under this new model, the Catalyst OpenCL components would also be reworked.

Latest Linux News
  1. KDE Applications 15.04.3 Fixes Bugs
  2. Benchmarks Of 54 Different Intel/AMD Linux Systems
  3. Linux 4.2 Bringing Support For ARCv2, HS38 CPU Cores
  4. Libdrm 2.4.62 Is An Important Update For Open-Source GPU Drivers
  5. The State of Unity 3D Game Engine, Editor On Linux
  6. ZFS On Linux 0.6.4.2 Brings Linux 4.1 Support, Fixes
  7. Old Net Burst Tests, Ubuntu Phone & Assembly x86 Were Popular Topics Last Month
  8. Qt 5.5 Officially Released
  9. Global Shortcuts In KDE Plasma Under Wayland
  10. LLVMpipe FP64 Support Knocks Off Some GL4 Extensions
Latest Articles & Reviews
  1. How KDE VDG Is Trying To Make Open-Source Software Beautiful
  2. Attempting To Try Out BCache On The Linux 4.1 Kernel
  3. CompuLab's Fitlet Is A Very Tiny, Fanless, Linux PC With AMD A10 Micro
  4. AMD A10-7870K Godavari: RadeonSI Gallium3D vs. Catalyst Linux Drivers
Most Viewed News This Week
  1. Kubuntu 15.10 Could Be The End Of The Road
  2. NVIDIA Starts Supplying Open-Source Hardware Reference Headers
  3. KDBUS Won't Be Pushed Until The Linux 4.3 Kernel
  4. The State & Complications Of Porting The Unity Editor To Linux
  5. The Staging Pull For Linux 4.2: "Big, Really Big"
  6. Latest Rumor Pegs Microsoft Wanting To Buy AMD
  7. SteamOS "Brewmaster" Is Valve's New Debian 8.1 Based Version
  8. Jonathan Riddell Steps Down From The Kubuntu Council