1. Computers
  2. Display Drivers
  3. Graphics Cards
  4. Memory
  5. Motherboards
  6. Processors
  7. Software
  8. Storage
  9. Operating Systems


Facebook RSS Twitter Twitter Google Plus


Phoronix Test Suite

OpenBenchmarking.org

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

AMD

Published on 30 July 2012 08:03 AM EDT
Written by Michael Larabel in AMD
33 Comments

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.

About The Author
Michael Larabel is the principal author of Phoronix.com and founded the web-site in 2004 with a focus on enriching the Linux hardware experience and being the largest web-site devoted to Linux hardware reviews, particularly for products relevant to Linux gamers and enthusiasts but also commonly reviewing servers/workstations and embedded Linux devices. Michael has written more than 10,000 articles covering the state of Linux hardware support, Linux performance, graphics hardware drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated testing software. He can be followed via and or contacted via .
Latest Linux Hardware Reviews
  1. Acer B286HK: A 28-inch UHD LED 4K Monitor For As Low As $350
  2. Intel Xeon E5-1680 v3 & E5-2687W v3 Compared To The Core i7 5960X On Linux
  3. Intel 120GB 530 Series SSD Linux Performance
  4. Btrfs/EXT4/XFS/F2FS RAID 0/1/5/6/10 Linux Benchmarks On Four SSDs
Latest Linux Articles
  1. Mesa Git Yields Performance Improvements For Newer AMD GPUs
  2. Apple OS X 10.10 vs. Ubuntu 14.10 Performance
  3. Mesa 10.5-devel Brings Some Intel Haswell HD Graphics Changes Over Mesa 10.3
  4. NVIDIA vs. Nouveau Drivers With Linux 3.18 + Mesa 10.4-devel
Latest Linux News
  1. KWayland Server Component Coming For KDE Plasma 5.2
  2. NVIDIA Posts Tegra Gallium3D Patch For K1+ Support
  3. Ubuntu 14.10 MacBook Air Tests With Linux 3.18, Mesa 10.5
  4. AMD Richland APU Support Added To Coreboot
  5. 2014 Holiday Shopping Reminder, Happy Thanksgiving
  6. Python 3 Support Added To The GNOME Shell
  7. ReactOS Lands Its New Explorer Shell
  8. Weston's IVI Shell Sees New Version
  9. IMP Launches As Another Open-Source Computer Attempt
  10. Git 2.2.0 Released With 550+ Changes
Latest Forum Discussions
  1. Updated and Optimized Ubuntu Free Graphics Drivers
  2. Hurrican SDL Port
  3. Roadmap to Catalyst 14.10 ?
  4. how to configure module phoromatic ?
  5. PulseAudio 6.0 Is Coming & Other Linux Audio Plans For The Future
  6. Debian Developer Resigns From The Systemd Maintainership Team
  7. Cant get working Kaveri APU - A10-7850k
  8. Script for Fan Speed Control