AMD's Open-Source Radeon Driver After Four Years

While the BFS scheduler is getting ready to celebrate its second birthday, in just three weeks AMD's open-source Radeon graphics driver strategy for Linux will be turning four years old. It was on the 6th of September in 2007 that I exclusively broke the news to the world on AMD's open-source strategy, which has ended up being a game-changer in the Linux world. AMD continues to support open-source hardware enablement on their latest graphics processors and recently even hired more developers to work on the code and documentation. How far have they come though in four years?

AMD's open-source graphics driver strategy was revolutionary. In early 2007 and prior, the ATI/AMD Radeon Linux support was notorious. Long ago, it would take easily a year (or at a minimum, several months) for new hardware to be supported by their Catalyst Linux driver, the Linux driver was missing core functionality, and overall it was just a messy situation. ATI Technologies had contributed some code and documentation in the past, even before the days of the fglrx Linux driver, but the 2007 strategy was a radical push forward under the control of AMD. In the months prior to the landmark 2007 announcement, the open-source community was left to come up with their own Radeon X1000 driver via reverse-engineering ATI's driver, which ultimately led to the short-lived xf86-video-avivo driver.

In 2007 to further reposition their Linux support, AMD introduced their new proprietary Linux driver, which happened to be yet another exclusive Phoronix story breaking the news days in advance of the driver's release. This new binary Linux driver brought new hardware support, much faster performance, and greater code-sharing between the Linux and Windows driver. Since that point, the Catalyst Linux driver has been on the same playing field with the Windows driver in supporting new Radeon/FirePro/FireGL GPUs, new features (e.g. CrossFire, PowerXpress, new OpenGL revisions), and other benefits.

With the 2007 open-source announcement also came the introduction of the xf86-video-radeonhd driver. This was to be the driver for all ATI R600 ASICs (Radeon HD 2000 series) and newer, but ultimately this driver died when support (via AtomBIOS rather than the direct register banging approach of RadeonHD) was added to the xf86-video-ati driver and then folded into the Radeon DRM driver for kernel mode-setting.

Since the 2007 change at ATI/AMD, the time that has been required for new hardware to be supported by the open-source Linux stack has been reduced a great deal. With the latest Radeon HD 6000 series and the Fusion APUs it's taken a couple of months for all the initial bugs to be worked out while building upon the code of previous generation graphics processors. It's still not as fine-tuned as Intel with their launch-day open-source support or the code that's even available prior to the hardware's availability (e.g. there's Intel Ivy Bridge code right now), but it's a step up from the time that it's taken in the past and even for the proprietary driver with the R500 generation and earlier where it was months/years. Going forward, and thanks to AMD's two new hires to work on the open-source driver, this initial time to hardware enablement will hopefully be reduced and ultimately may hit a point of same-day support. At least the Catalyst Linux driver now supports all new hardware at launch.

Advanced Micro Devices has also continued to push out new design documentation to the open-source community in a public and NDA-free manner. Unfortunately, the pace of new document drops has slowed a bit, but John Bridgman and his team are still working. Document drops are also coming after the time of initial hardware enablement, since due to the limited open-source staff, the documentation is being compiled at the same time the initial code is being written in order to determine what register information and other data is actually needed and useful. There's also still undocumented blocks, such as for the Unified Video Decoder engine that's not being publicly implemented at this time over fears of it compromising the Digital Rights Management mechanisms on other platforms.