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

Written by Michael Larabel in Display Drivers on 22 March 2014. Page 3 of 3. 158 Comments

It will be interesting to see how they're able to work around some of these issues and hopefully overcome them to deliver this revised Linux graphics driver stack. The Radeon DRM kernel driver certainly has the potential of becoming closer to feature and performance parity with the Catalyst driver as it stands now, but it will be fascinating to see how the Catalyst user-space can morph to work with the Radeon Direct Rendering Manager driver and whether it will be justifiable in terms of additional engineering resources and whether it will lead to an improved AMD Linux experience or ultimately to a setback for user features/functionality compared to the case now with the completely standalone Catalyst binary driver. I certainly would love for this approach to work as it would mean a more stable Linux experience, far less fragmentation, the Radeon DRM driver finally being "first class", greater investment into the open-source driver stack, and never being bound to running old kernels for API/ABI compatibility, and the binary blob now being limited to user-space.

In recent times within the ARM SoC world we have seen some vendors produce open-source kernel graphics drivers with a binary-only user-space, but these other drivers haven't had to support two different user-space drivers, these kernel drivers do not comply with the Direct Rendering Manager subsystem, and they are not part of the mainline Linux kernel due to being dependent upon the user-space blobs.

For those wondering why AMD doesn't just completely open-source the Catalyst code-base, I posed that question again to AMD this week. While Linux users have traditionally been quick to think that AMD doesn't open-source their driver over "third-party IP/code", that apparently isn't the primary reason. It was explained that there's little third-party code/dependencies within the Catalyst code-base and that AMD has even licensed Catalyst code-base to some (undisclosed) licensees in the past. Thus the Catalyst code-base has already been scrubbed to make it licensable and these "third-party" reasons for not open-sourcing the driver is actually a common misconception. One of the big reasons for not open-sourcing Catalyst remains concerns about AMD's "secret sauce" within their OpenGL driver code in having a competitive advantage with having some hot optimizations within the driver and other novel code that they would prefer their competitors to not see or utilize. There apparently aren't many secrets within AMD's kernel code.

Also expressed was that AMD doesn't have much to gain from a business perspective in open-sourcing the Catalyst code-base. Just as AMD would provide more public documentation and quicker if it meant more contributions to their existing open-source driver, open-sourcing the Catalyst driver would likely not lead to a sudden increase in contributors. Catalyst is millions of lines of code and incredibly more complicated than the Radeon Gallium3D drivers that are less than one hundred thousand lines of code. With the open-source Gallium3D drivers as it stands today, plus the available documentation and register specifications, there isn't a magical stream of contributions by many independent open-source developers. Most of the open-source AMD driver work done today is by only a handful of developers outside of AMD. Having a code-base that's incredibly more complex and that's also been around much longer would likely not yield any business case for AMD, especially with the overall Linux market being quite small still and the number of users devout to only open-source code being even smaller. In terms of the current Catalyst code-base I was told that it's a couple million lines in total while there's only a few thousand lines that are platform specific with what would need to be reworked for this new driver model.

With regards to why Catalyst is being kept around and just not abandoned in favor of the open-source Radeon driver with Gallium3D that is slowly but surely catching up with OpenGL support, hardware features, and performance, is that Catalyst is still very important in the enterprise market. In particular, Catalyst is important to many users for its OpenGL compliance and driver certifications. AMD invests a lot into quality assurance and seeing that Catalyst fulfills their large commercial customer's needs, which aren't met by the existing open-source driver. There's also many more highly tuned OpenGL optimizations within Catalyst that likely won't materialize within the open-source driver without a lot of hard to justify, painstaking work.

Also, I'm told these Linux changes will not affect the Windows Catalyst driver. "The kernel models are very different between Linux and Windows and we currently don’t really share any code there."

Overall, that's where things stand today with regard to AMD's Catalyst driver on Linux and their outlook going forward. It will be very interesting to see if they can get Catalyst running on an open-source kernel driver but that likely won't be clear for some time, so stay tuned to Phoronix for the latest information. AMD made it very clear that they are committed to Linux and are actively working to improve their Linux support with the resources they have available while paying attention to see how SteamOS and the other recent Linux gaming initiatives take-shape. It was acknowledged that the Catalyst Linux driver isn't perfect but they are becoming more Linux friendly, doing what they can with the resources they have, and they are trying their best.

In the interest of transparency, AMD sponsored the Phoronix trip to GDC 2014 in order to meet-up and talk about their Linux plans.

If you enjoyed this article consider joining Phoronix Premium to view this site ad-free, multi-page articles on a single page, and other benefits. PayPal or Stripe tips are also graciously accepted. Thanks for your support.

Related Articles
About The Author
Michael Larabel

Michael Larabel is the principal author of and founded the site in 2004 with a focus on enriching the Linux hardware experience. Michael has written more than 20,000 articles covering the state of Linux hardware support, Linux performance, graphics drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and automated benchmarking software. He can be followed via Twitter, LinkedIn, or contacted via