While we are still waiting on open-source support for the AMD Radeon HD 6000 series of graphics cards that were released last month, today AMD is releasing their initial open-source support for their Ontario hardware. AMD's Ontario is their low-powered Fusion processor designed for use in netbooks and other such devices. This dual-core chip with integrated Radeon HD 6250 graphics is only starting to ship now, but the open-source support for this first AMD Fusion chip is now available to Linux users, complete with 3D support.
This news shouldn't come as a surprise seeing as just last week we reported AMD already has open-source Fusion drivers but that they were waiting to finish up the code's legal review process before pushing it out. That process is now complete and the initial Ontario push is happening this very minute. This work includes DDX (xf86-video-ati), Mesa, and Radeon kernel DRM changes. This initial Mesa 3D support is heading into the classic R600 DRI driver rather than the Gallium3D "R600g" driver. Though based upon how quickly Evergreen got Gallium3D after its support was added to the same classic driver, we anticipate that the Fusion Gallium3D support is not too far out. As shown by our brand new Radeon Gallium3D benchmarks, this right away should result in better performance besides the capabilities provided by the different state trackers and other features. Edit: Gallium3D support for the Fusion APUs was just pushed minutes after the rest of the code push!
This AMD Fusion Linux support was written by AMD's Alex Deucher. John Bridgman of AMD says this initial open-source support should be at around the same level of support and capabilities as where the open-source Radeon HD 5000 "Evergreen" support is at right now. This includes user-space mode-setting, kernel mode-setting, 2D EXA, X-Video, and 3D/OpenGL support. John also said a bulk of the changes in bringing up the Ontario support is within the Radeon DRM kernel area. "The graphics portion of Ontario is very similar to the entry-level Evergreen GPU, at least for the portions used by the open drivers. There are a few enhancements but we haven't looked at those yet. We want to get Northern Islands supported next."
While the Radeon HD 6000 "Northern Islands" hardware doesn't yet have open-source support, it's good to see the Ontario support already here when it's still difficult to find any devices actually deploying this hardware yet. Hopefully in the future we will see AMD become more prompt at providing open-source support (with the Radeon HD 5000 series that launched last year we just got the accelerated open-source support htis August). This is the best turnaround time we have yet to see from Advanced Micro Devices since they adopted an open-source strategy more than two years ago, but it's still not as quick as Intel (for the Sandy Bridge CPUs they are launching in January they have been publicly working on Linux support since February and expect to have complete support done this quarter and in the mainline code-bases).
Prost (cheers), to AMD on another open-source code drop!
Based upon the timing right now, the kernel DRM changes for AMD Ontario will not hit the kernel until the Linux 2.6.38 release. Getting the DRM changes into the Linux kernel is the most important part as most users are uncomfortable building and patching their own kernels while the 3D portion should find its way into Mesa 7.10, which is expected for release this quarter or early next year, and the xf86-video-ati DDX support will be in the 6.14.0 release but most distributions tend to pull Git snapshots of this X.Org driver anyways. This all means it will not be until around the Q2'2011 Linux distributions (Ubuntu 11.04, MeeGo 1.2, Fedora 15, etc) and later that there will be "out of the box" support for this hardware on Linux.
The AMD Ontario processor is designed to compete against the recent Intel Atom CPUs in the mobile device space. The power consumption is slated to be 9 Watts TDP, but it will be interesting to see how the open-source power management compares especially with the CPU and GPU being coupled. Sadly, the Fusion UVD (Unified Video Decoder) block is no different from the video decoding capabilities found on current Radeon HD GPUs, which means it will be unlikely to see any UVD documentation or official open-source support for accelerated video playback (beyond the minimally-helpful X-Video) since this could potentially compromise their Digital Rights Management protection on other platforms. At least though we can have X-Video Motion Compensation (XvMC) when using a shader-based implementation on Gallium3D rather than tapping the UVD block itself, which is successful in moving more of the workload from the CPU to GPU compared to X-Video. Catalyst driver users meanwhile can attempt to use XvBA with UVD on Linux, but that's still a big mess. In the future it would be ideal to see open-source VA-API or VDPAU support for Radeon hardware on Linux.
For those wondering about Fusion hardware documentation, we haven't been told when AMD may release such register specifications, etc for this new hardware.
This open-source Fusion support joins AMD's proprietary Catalyst driver for Linux that sports complete support for this hardware. This release is also just coming two weeks after AMD announced they would be joining the MeeGo project to better embrace mobile Linux. As soon as we can find some AMD Ontario hardware we will have up the Linux benchmarks.
Update: This article was written this morning in advance of the public code drop. Now that we have our eyes on this code, it is indeed very exciting to see there's both classic Mesa and Gallium3D support for AMD Fusion and not just R600c support like we were originally told. In particular this initial support mentions the Fusion "Palm" graphics chip, which we're now told are Evergreen ASICs. There's also a reference to "Sumo" when it comes to the new firmware for Fusion, of which there are three new firmware/micro-code files. Four new PCI IDs are listed as part of this support within the DRM and Mesa drivers. Some of the patches now hitting the dri-devel mailing list include support for other features too like power table parsing, blit support, and thermal sensor support.