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. Even With Re-Clocking, Nouveau Remains Behind NVIDIA's Proprietary Linux Driver
  2. The Power Consumption & Efficiency Of Open-Source GPU Drivers
  3. AMD R600g/RadeonSI Performance On Linux 3.16 With Mesa 10.3-devel
  4. Intel Pentium G3258 On Linux
Latest Linux Articles
  1. Updated Source Engine Benchmarks On The Latest AMD/NVIDIA Linux Drivers
  2. Nouveau vs. Radeon vs. Intel Tests On Linux 3.16, Mesa 10.3-devel
  3. KVM Benchmarks On Ubuntu 14.10
  4. X.Org Server 1.16 Officially Released With Terrific Features
Latest Linux News
  1. Unreal Tournament Looks Great For Team Deathmatch
  2. LibreOffice 4.3 Released With Many Exciting Changes
  3. GNOME/GTK On Wayland Gains Focus At GUADEC
  4. GNOME Stakeholders Take Issue With Groupon Over their Gnome
  5. GStreamer VA-API Plug-In Update Adds New Features
  6. Qt 5.4 Going Into Feature Freeze Next Week With Exciting Changes
  7. OpenSUSE Factory Turns Into Rolling Release Distribution
  8. "The World's Most Highly-Assured OS" Kernel Open-Sourced
  9. NVIDIA Is Working Towards VDPAU H.265/HEVC Support
  10. Hawaii Bug-Fixes Start Hitting Mainline RadeonSI Gallium3D
Latest Forum Discussions
  1. Open-source drivers on ATI R7 260X
  2. AMD Athlon 5350 APU On Linux
  3. Grand Theft Auto Running On Direct3D Natively On Linux Shows Gallium3D Potential
  4. Linus Torvalds On GCC 4.9: Pure & Utter Crap
  5. Updated and Optimized Ubuntu Free Graphics Drivers
  6. Debian + radeonsi
  7. List of Linux friendly Kickstarter projects
  8. Porting Mesa to the Playstation 2