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.org

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 - 156 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.

<< Previous Page
1
Latest Linux Hardware Reviews
  1. Preview: AMD's FX-9590 Eight-Core At Up To 5.0GHz On Linux
  2. Intel Launches The Core i7 5960X, Mighty Powerful Haswell-E CPUs
  3. AMD Radeon R9 290: Gallium3D vs. Catalyst Drivers
  4. AMD Radeon R9 290 Open-Source Driver Works, But Has A Ways To Go
Latest Linux Articles
  1. How Intel Graphics On Linux Compare To Open-Source AMD/NVIDIA Drivers
  2. The Fastest NVIDIA GPUs For Open-Source Nouveau With Steam Linux Gaming
  3. Testing For The Latest Linux Kernel Power Regression
  4. The Most Energy Efficient Radeon GPU For AMD Linux Gaming
Latest Linux News
  1. Nouveau X.Org Driver Released With DRI3+Present, Maxwell, GLAMOR
  2. Microsoft & AMD Release C++ AMP Compiler With Linux Support
  3. AMD, Wine & Valve Dominated August For Linux Users
  4. Linux 3.17-rc3 Kernel Released Back On Schedule
  5. Lennart Poettering Talks Up His New Linux Vision That Involves Btrfs
  6. Mesa 10.3 RC2 Arrives Via Its New Release Manager
  7. Ubuntu 14.10's Lack Of X.Org Server 1.16 Gets Blamed On AMD
  8. MSI Motherboard BIOS Updating Remains A Pain For Linux Users
  9. See How Your Linux System Performs Against The Latest Intel/AMD CPUs
  10. AMD Steppe Eagle Flys To Coreboot
Latest Forum Discussions
  1. Lennart Poettering Talks Up His New Linux Vision That Involves Btrfs
  2. Updated and Optimized Ubuntu Free Graphics Drivers
  3. AMD Releases UVD Video Decode Support For R600 GPUs
  4. SSD seems slow
  5. Is laptop with Intel CPU and AMD dGPU worth buying considering especially AMD Enduro?
  6. Radeon HD5670 and Ubuntu 14.04
  7. Btrfs Gets Talked Up, Googler Encourages You To Try Btrfs
  8. Updated graphics drivers for Ubuntu 12.04 Precise LTS