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

<< Previous Page
1
Latest Linux Hardware Reviews
  1. A Walkthrough Of The New 32 System Open-Source Linux Benchmarking Test Farm
  2. Habey MITX-6771: Mini-ITX Board With Quad-Core J1900 Bay Trail
  3. OCZ Vector 150 SSD On Linux
  4. Noctua i4 CPU Cooler: Great For Cooling High-End LGA-2011v3 CPUs
Latest Linux Articles
  1. AMD Kaveri: Open-Source Radeon Gallium3D vs. Catalyst 14.12 Omega Driver
  2. 12-Way AMD Catalyst 14.12 vs. NVIDIA 346 Series Linux GPU Comparison
  3. AMD Catalyst 14.12 Omega Driver Brings Mixed Results For Linux Users
  4. 6-Way Winter 2014 Linux Distribution Comparison
Latest Linux News
  1. An Open Hardware Random Number Generator Proposed
  2. LLVM 3.6 Will Be Branched Next Month
  3. Opera Browser Puts Out Linux Updates For The Holidays
  4. GNOME Shell 3.15.3 Adds Support For High-Contrast Themes
  5. Linux 3.19: ThinkPad Muting Redone, New Dell Backlight Support, Acer Is Banging
  6. KVM Drops Support For IA64 While Adding Various x86 Improvements
  7. GCC 4.8.4 Officially Released
  8. FSF's High Priority Project List Now Has A Committee
  9. Details On Using OpenACC & GPUs With GCC
  10. Ubuntu 15.04 Alpha 1 For Its Various Flavors
Latest Forum Discussions
  1. Need some hand holding with upgrading xserver
  2. XLennart: A Game For Systemd Haters With Nothing Better To Do
  3. The New SuperTuxKart Looks Better, But Can Cause GPU/Driver Problems
  4. Debian init discussion in Phoenix Wright format
  5. FPS capped on Linux (AMD fglrx drivers)
  6. Are there an app using HSA ?
  7. Bench specific mount point
  8. Tool for measuring FPS in games