AMD Open-Source S.I. Botched, Hope For The Future

We're now going into eight months since the AMD Radeon HD 7000 series "Southern Islands" graphics cards first launched. In that time the Catalyst Linux support has been stable and fine, but the open-source driver support is still unusable.

There has been the DRM/KMS support already for the Southern Island GPUs within the mainline kernel, so there is kernel mode-setting support, but not much more. There is the new RadeonSI Gallium3D driver to provide the user-space 3D/OpenGL driver support, but that isn't yet in a working state. Getting RadeonSI up and running is the main blocker right now for usable Radeon HD 7000 series open-source support. There isn't even 2D acceleration support yet since its using GLAMOR and so first the 3D code-paths must actually work.

Following the recent Phoronix posting about new state handling for the RadeonSI driver, John Bridgman of AMD who leads their open-source GPU driver strategy and is the prolific Phoronix Forums poster, shared some additional details within this thread about current and future support.

As far as why the HD 7000 series open-source Linux support isn't yet working, he repeats the same answer as before: it's a big undertaking.

One part is that different HW vendors don't make big architectural changes at the same time. A better comparison might be Trinity vs Ivy Bridge, both of which had support before launch, although as I understand it the Ivy Bridge changes were probably somewhere between Trinity and SI in complexity.

Basically that the Radeon HD 7000 series graphics processor is fundamentally quite different from previous generations of hardware, so there's a lot of work to do... The GCN architecture is in fact quite different, but sure they could have done more to prepare to prior to launch or sought additional resources since it's their customers that are now waiting more than a half-year for this hardware support.

Second part is that we've been catching up over the last 5 years (as a bunch of people have already mentioned) and are almost-but-not-quite caught up. SI was the first new GPU generation where we were able to get substantial work done before launch, but that still meant we were working almost a year behind Catalyst. The next generation will be the first where open source graphics driver development is able to run more or less in parallel with Catalyst development work -- agd5f already has initial kernel driver support written.

So the good news is that it looks like for the AMD Radeon HD 8000 series the open-source work is being done in parallel with the proprietary Catalyst driver enablement. Alex Deucher of AMD has the KMS driver written.

Yep, that's what we were hoping for as well. The code has been written and published for a while, but it's hard to predict how long it will take for the last few "in theory we're programming it right but in practice something is obviously wrong" gotchas, although the range of variation goes down significantly if you are debugging the code early enough to lean on emulators and HW debug teams a bit.

Bridgman doesn't know when the Gallium3D HD 7000 series support will actually begin to work.

Tom is a fairly big part of the open source OpenCL effort for GPU compute on Linux inside AMD (obviously it *is* open source and there are other devs outside AMD working on it as well). There is a larger team working on GPU compute via Catalyst, plus the whole HSA effort.

Tom Stellard of AMD continues to devote most of his time to bringing up open-source OpenCL support for the Radeon driver. Unfortunately there the code is in a similar case to the HD 7000 series: it's still very premature and not ready for end-users. Galliun3D OpenCL isn't even being packaged for Fedora at this time and it will likely not be until 2013 when there is satisfactory open-source OpenCL support on GPU hardware.

AMD has not yet opened up all of the PM bits of the GPU (but as I said before we are working on that again since it doesn't look like community devs are going to go any further with what has already been released), so it loses in the performance-per-watt when the system is idle...

As talked about this weekend in AMD Releases ACPI Header For Open-Source GPU Driver, the small AMD open-source team is also still trying to tackle better (effective) power management for the Radeon graphics cards.

I can't go into detail at this point, but the goal is to give decent dynamic PM and crank up the clocks on APUs. Speculating on release timing is just that -- could be soon, could be a long time, could be never. I think never is unlikely though.

As with most things out of the AMD open-source camp, there isn't any defined timeline for having much better power management support.

We try to plan the development and IP release activities so that community developers and AMD developers can work in parallel, ie we focus on getting enough initial code and programming info out to let community developers continue while we go work on the next chunk of hardware.

We knew that video decode acceleration via UVD would be hard and we tried to make it very clear from day one that people should *not* assume there would be open source video decode accel support. PM was a different story though... it was pretty simple at the time we made plans for the open source effort but changed radically over the first couple of years.

Alex pushed out basic PM code a couple of years ago (2009 maybe ?) and I expected that community developers would continue to improve PM using information we had released in the same way they did on 3D and other areas... based on feedback from various devs it looks like I called that one wrong in a couple of ways.

First issue was that working on PM code turns out to be regarded as a lot less fun than working on pretty much anything else, second issue was that the devs who *were* willing to work on PM also had access to some of our longer range plans under NDA and didn't want to invest in the current code since there was a non-trivial chance that future code/info releases from AMD might obsolete their work. Makes sense, unfortunately.

As a result, the current PM code hasn't been improved and everyone is waiting for our "future plans" to happen instead, all for perfectly good reasons. D'oh !!

We have bumped the priority of the next round of PM work, but that doesn't make vacations go away and it doesn't do anything for the uncertainty about what we will eventually be able to release.

Not many community developers are interested in hacking on Radeon GPU power management code, unfortunately.

Not a schedule per se -- we basically work on documentation in the "free time" (ha ha) left over after implementing and releasing enough initial support that we know what needs to go into the documentation, and there won't be a lot of that until we are fully caught up with hardware development and can start leveraging more of the work being done by other teams.

First doc out will probably be the SI ISA guide (which is worked on by a number of teams inside AMD) then we'll backfill around that with SI graphics programming information and try to start filling some gaps in the earlier GPU generations.

There isn't yet published any official Radeon HD 7000 series programming documentation nor is there a timeline for getting this data out of AMD's door. The first doc to likely come will cover the new graphics processor's Instruction Set Architecture.