While we still haven't been able to deliver any Radeon HD 7000 series
Linux benchmarks, we do know what are AMD's three priority projects right now for their open-source Radeon Linux driver stack.
The three priorities right now for AMD and their open-source Linux driver stack come down to Southern Islands support, OpenCL, and UVD/video. If you're part of the Phoronix Forums
community, this shouldn't come as much of a surprise since it was there where this information was first shared.
Thanks, of course, to John Bridgman at AMD with more than six-thousand posts in our forums where he continues providing useful information and keeping the Phoronix community informed on AMD's leading open-source Linux efforts. (This is absolutely great, since the PR officials at AMD -- and other companies -- often never have a clue about Linux, as I'm so frequently reminded when at events like CES
From this thread
, "Right now the priorities are SI support, OpenCL and figuring out if we can release some kind of UVD support."
Southern Islands Support:
This shouldn't be any surprise... AMD released the first "Southern Islands" GPU, formerly known as Graphics Core Next (GCN), at the end of December as the Radeon HD 7970. Other Radeon HD 7000 series GPUs are imminent and AMD is wanting to support this latest hardware quickly under open-source (it's already supported by the Catalyst driver) so that you can go out and buy this new hardware. In terms of the current Radeon HD 7000 series Linux state, read AMD Radeon HD 7970 Open-Source Linux Update
and Radeon HD 7000 Series Linux Driver Support
In a Phoronix Forums follow-up
, Bridgman adds "The SI support we are working on refers to Southern Islands. Before we launched the HD 7970 I was referring to it as GCN since that was the only name we had made public. First priority was getting the foundation changes working and released (multiple ring support, GPU VM, LLVM back end), now the focus is shifting more towards SI-specific bits." The Radeon VM support
he mentions landed in the Linux 3.3 kernel
just recently, the R600g LLVM back-end
came in December, and various other prerequisites have been recently tackled.
There's no word at this time on when the Radeon HD 7000 series open-source Linux support may land. It will bring a new user-space Gallium3D driver (derived from R600g) and will require more kernel DRM changes, which could theoretically land in Linux 3.3 if it doesn't touch the support for any older hardware. However, don't expect mature Southern Islands support until the H2'2012 Linux distributions. For now the best bet is sticking to the Catalyst Linux blob for the latest and greatest hardware support.
In terms of when there might finally be Radeon HD 7000 series Linux tests (either on open or closed-source Linux drivers), I asked AMD about it this week
... When I was not busy being entertained by Microsoft
, Intel's overwhelmingly Windows demos
, or the Intel incompetent employees about Linux
. They've had a supply shortage on the Radeon HD 7970, but will try
to get out an HD 7970 soon so I can run some Linux tests. Otherwise when the next Southern Islands hardware launches I'll hopefully have some hardware.
With AMD's latest graphics hardware being designed to support OpenCL/GPGPU quite well, AMD now obviously wants this compute support on the open-source side. Tom Stellard at AMD and others have been working towards the open-source OpenCL goal going back to last year with the LLVM back-end for their Gallium3D driver, the on-going work to the "Clover" state tracker
, etc. It will likely be some months though before all of the pieces properly land for doing OpenCL off of your Radeon GPU with an open-source stack.
John Bridgman and others at AMD still don't have a clue whether they can expose any Unified Video Decoder (UVD) documentation or code. The long-standing issue with open-source UVD information is exposing this video decode/encode engine that's found on modern generations of Radeon hardware, but without compromising AMD's Digital Rights Management abilities on other platforms (Microsoft Windows). Any code or documentation is likely to face very stiff legal review internally at AMD, based upon it taking months of review even for features like HDMI audio, etc.
For now the best means of video acceleration on the open-source stack is using the VA-API/XvMC state tracker in Gallium3D, which will provide some GPU acceleration using shaders and not the dedicated UVD engine. Right now the open-source UVD support is just a hopeful feature, but future generations of Radeon UVD hardware are purported to be more open-source friendly by being more modular so that the ASIC can be documented without blowing up the Digital Rights Management.
Here is the latest Bridgman quote on the matter of UVD, "Officially UVD is still off the table, but I also said that we would see if we could find ways to provide some level of support. We started working seriously on that in mid-2011. I don't know at this point if we will be able to release anything, however. We left this effort until later in the program because it's a lot of work with no guarantee of success, ie we may spend a lot of time on it and in the end not be able to release anything."
Plus here's a few Bridgman extras:
While there is Evergreen HDMI audio support
finally found in the Linux 3.3 kernel, it came via community reverse-engineering
. AMD has written some proper patches for modern HDMI audio support in their open-source driver, but the code has long been tied up in AMD legal review
John says that the internal HDMI audio patches are basically better than this basic reverse-engineered support. "The work Alex did was more comprehensive but also more challenging to release."
For those still wanting better power management out of the open-source Radeon driver... "[Power management] is somewhere on the list but in general we are trying to focus our devs on things the community would have a tough time doing without us either writing documentation or providing an initial implementation. Power management is a bit unusual in the sense that the current implementation could be improved significantly with the information that is already available (improving the interpretation of specific BIOS images, fixing up dynpm to work in more cases) *and* we are trying to release other hardware bits as time permits."