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

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.