AMD Is Exploring A Very Interesting, More-Open Linux Driver Strategy
I would love for this plan to work, but the issues I currently foresee in this proposed approach include:
- Significant code re-factoring would likely be needed to the Catalyst OpenGL driver and the Catalyst DDX so that it could work with the Radeon DRM kernel driver. Right now Catalyst is under a very different driver model compared to the open-source Linux Direct Rendering Manager and Direct Rendering Infrastructure so a sizable code rework would need to be done to all the Catalyst user-space code. AMD's Linux work is already stretched thin with hearing repeatedly at GDC about their "engineering costs" in not being justifiable in matters like providing better Catalyst driver change-logs or other documentation, etc. However, some of these concerns have already been eased with AMD's Graham Sellers saying, "We have done some experiments and have been able to hook the closed source Catalyst OpenGL driver up to an unmodified open source kernel mode driver and communicate with the GPU. This is far from production code, but my feeling is that there is not a substantial barrier here. The vast, vast majority of the OpenGL driver code is in user mode space."
- Linus Torvalds doesn't accept code into the mainline Linux kernel that breaks the user-space interfaces, thus making drastic changes to the Radeon DRM kernel driver to adapt more to the Catalyst user-space code is out of the question if it will break existing support for the current libdrm code with the R300/R600/RadeonSI Gallium3D drivers and the xf86-video-ati X.Org driver. It would be the Catalyst code that needs to workaround and add to the current Linux kernel interfaces. However, it seems they think they may be able to break the Linux kernel user-space interfaces for the Radeon DRM driver, "As for changing the user-mode interface in the kernel, that may need to happen as we add features, but I’m not expecting significant churn. Whatever happens there, it would be a coordinated and well documented effort, and where possible, we will exercise those interfaces in the open source drivers."
- It's not clear that the Radeon DRM kernel driver in its current form would be up to the task. The Radeon DRM memory management code is less optimized compared to Catalyst and there's other performance improvements that would be needed so that it wouldn't be a performance loss in switching to this new driver architecture.
- Besides needing to enhance the Radeon DRM performance, there's numerous features currently missing from the open-source Radeon Linux driver code. While some features are limited to just user-space, among the features that immediately come to mind as missing from the open-source driver are CrossFire / Dual Graphics, OpenGL stereo support, advanced AA/AF modes, OverDrive / overclocking, and various other options currently exposed as tunables through the AMD Catalyst Control Center. The open-source AMD OpenCL support is also incomplete. The current open-source driver stack is limited to OpenGL 3.3 compliance instead of OpenGL 4.4 as provided by Catalyst. In response to this concern I was told, "While there are indeed features that DRM lacks that we have in the Catalyst stack, the same is true in the other direction. We have no support for VCE in Catalyst, for example. This is really just an engineering man-power issue (on both sides), and each team has chosen to expose different features. Hopefully, having only one kernel mode component to support should allow us to support more features in both drivers, which is good for everyone."
- It's not clear how AMD would handle patent-encumbered or legally risky code that needs to reside within kernel-space. Digital Rights Management is one of the main items that come to mind for how they would implement in Catalyst over an open-source kernel driver. One possibility would be a secondary, closed-source kernel module to provide extra functionality not possible with an open-source kernel driver. However, if this approach would be taken it still would present AMD Linux users with the same issues of having a binary kernel module that requires a compiler to be present on the system at install time, broken API/ABI compatibility with new kernel releases, and other fragmentation issues. If these sensitive bits didn't require many kernel changes but could be pushed down the command stream to the hardware, with a fully open kernel driver the user-space bits could be more easily reverse-engineered.
- In continuation of the previous concern, if new kernel interfaces / ioctls were added to the open-source Radeon DRM driver but were just utilized by the closed-source Catalyst user-space, the work might not be accepted into the mainline Linux kernel. Linus Torvalds has previously rejected code from being upstreamed that effectively was only utilized and tested by closed-source user-space bits. One main example was for the VIA Chrome 9 DRM driver that VIA Technologies previously tried to push upstream was rejected as the 3D support was only supplied via a binary-only user-space component.
- According to some of my sources, there previously was a similar proposal at AMD back around 2007 for having Catalyst become just a user-space driver. This similar proposal was rejected back then. According to one of my sources, "a lot of this stuff is layered in a way that it is hard to make catalyst work in [the open-source kernel driver] framework." But since then I'm told the Catalyst driver has been greatly reworked.
- An important focus for the Catalyst driver is on the enterprise Linux market... Right now the Catalyst driver can be easily installed on older kernels with ease, particularly the Enterprise Linux kernels that have Long Term Support. With this new model, a lot of Radeon DRM code would need to be back-ported to the existing LTS/EL kernel releases and this might not work out too well for kernel maintainers/vendors and commercial Linux users that would need to now upgrade their kernel for new Catalyst support plus the user-space blob as opposed to just running the new driver installer and building a new fglrx kernel module.
- On a similar concern to the previous, any bug-fixes and improvements to the Catalyst driver for current stable (non-rolling-release) distributions would now involve the user having to upgrade the kernel (either to a new major release or a new point release if the Radeon DRM changes are back-ported). Not many tier-one Linux distributions so easily or quickly push down major kernel versions for their already released operating system versions, which would be a setback compared to the situation now where you can go to AMD.com and download the complete Catalyst driver package to install on your existing operating system stack.
- AMD would need to commit to Radeon DRM hardware enablement work and other changes earlier in the development of next-generation hardware to see that stable kernel releases used by tier-one distributions are shipping with suitable kernel code. Up to now the support for major GPU revisions has landed after the hardware is already on the market, and given that it can take up to a few months to appear in a released kernel given the policy of merging major code into mainline kernel only during the "merge window" that is just open for about two weeks after two months or so and then several weeks of release candidates, AMD will need to get its timing together. In some cases the new open-source hardware support isn't held up by programmer bottlenecks but for the Linux developers to obtain permission to publicly release the code after clearing legal/technical reviews internally at AMD. For reference, Intel first submitted "Broadwell" graphics support for their Intel kernel driver last year and it's still being refined in succeeding updates all to have the support ironed out for a nice "out of the box" experience as soon as these new processors ship.
- Besides new hardware enablement, other features have taken a while to clear legal/technical review and be permitted to be released as open-source software. Only with the Linux 3.15 kernel that will be officially entering development in the coming days is there VCE video encoding support for hardware that's long been on the market. The VCE video encode engine will finally appear in a released kernel in over two months. On a similar note, only a few kernel releases ago was Radeon Dynamic Power Management and HDMI audio support even enabled by default for the open-source kernel driver while the Catalyst driver has supported such functionality from day one with new hardware. Major processes will need to be improved upon internally at AMD so that Linux users won't be left out in seeing new functionality appearing timely within the kernel so that Linux Catalyst users are not running with a reduced feature-set compared to Catalyst on Windows.
Those are among the challenges and cons to the proposal that have come to my mind since learning the news on Thursday.