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.