AMD Radeon HD 7970 Open-Source Linux Update
AMD launched the Radeon HD 7970 graphics card yesterday as the first built upon their GCN (Graphics Core Next) architecture. Besides the initial Phoronix coverage of this first "Southern Islands" product, there's some new open-source Linux driver information today.
Yesterday's article summarizes the current level of Linux support for this new fastest single-GPU graphics card: the AMD Catalyst binary driver support is there but there's no open-source driver support available. There's Radeon HD 7000 series open-source support being worked on by AMD, but there's nothing public at the moment and it will likely be several months before there is usable and reliable open-source support (DRM/KMS and Gallium3D).
While AMD didn't send out a Radeon HD 7970 "Tahiti" graphics card sample to Phoronix for launch-day nor have they or any of their AIB partners contacted Phoronix yet about sending over a Radeon HD 7970 in order to provide Linux support and performance information to the Linux community, we do have one advantage: John Bridgman. Fortunately, the head of AMD's open-source graphics driver strategy is also the number-one poster in the Phoronix Forums -- he has more than 6,000 posts!
He provided bits of Graphics Core Next Linux information prior to launch, but now that there's hardware out there and plenty of public information, Bridgman can provide greater comments. So even without hardware in hand or AMD's PR department caring much about Linux coverage, we at least have Bridgman to fill in some of the gaps. In the day since the Radeon HD 7970 unveiling, there's been new open-source driver information learned from the Canadian hunter.
His first comment after the HD 7970 launch was just confirming information about their LLVM Gallium3D driver back-end: "the plan is for the new compiler code to go into the Gallium3D driver and process GCN graphics shaders (after adding GCN instruction generation, of course) along with compute for all architectures, while pre-GCN graphics shaders will go through the existing r600g compiler/translator."
In another comment he also provided an update about the open-source UVD support status... But there basically isn't anything new. Him and his colleagues still need to examine the Unified Video Decoder more closely and the latest GCN revisions to see if they can provide any open-source video encode/decode using this engine. The show-stopping problem is that they haven't been able to open up any code or documentation for this video engine since it could potentially compromise the Digital Rights Management abilities on other platforms, so for now video decode is limited to using shaders under Gallium3D with the VDPAU/VA-API/XvMC state trackers.
John expects to take another stab at looking at UVD in 2012. There's long been talk of future generations of Radeon graphics processors having a more modularized UVD engine so that part of it could be opened if the DRM component was decoupled from it.
In terms of the PowerTune support with the Radeon HD 7000 series, John says, "I don't think we have looked at PowerTune specifically; my guess is that the first chance to do that will be a few months from now. There are some more fundamental power management improvements I would like to get out first, and they will probably be a pre-requisite for PowerTune anyways." Power management is currently an open-source sore spot.
In this other comment, Bridgman talks more about the rendering and compute paths of R600+ and Southern Islands in terms of the IR and conversions. In terms of the GCN workflow:
For GCN graphics the Gallium3D pipe driver will receive TGSI shader programs from Mesa, use "part 1" of the newly released code to convert TGSI to LLVM IR, then use "part 2" to generate GCN GPU instructions from the LLVM IR
For GCN compute the Gallium3D pipe driver will receive LLVM IR kernel programs from clover (or other compute front ends) then use "part 2" of the newly released code to generate GCN GPU instructions from the LLVM IR
In yet another post by John Bridgman is more information about the GCN compiler in Catalyst, IRs, and other technical details for Phoronix enthusiasts. It's one of John's lengthier posts, but it's worth a read if you're into the low-level graphics/compute details.
In a recent post he adds even more details and addresses various Phoronix reader questions. An interesting detail from that post is that he talks of getting the invasive kernel DRM driver changes into the Linux 3.3 kernel merge window. This would mean AMD would need to get the code published in the next few weeks and to quickly make it through public review. The invasive changes are for handling multiple rings, memory management changes, and other low-level areas.
Bridgman doesn't know when the actual GCN enablement code will be published for mainline kernel integration, but since that's all about new hardware support and shouldn't affect existing Radeon GPUs, that could be merged after the 3.3 merge window is closed. However, when that code is ready and clears legal review is another story. Most Radeon HD 7000 series owners though won't actually see a good "out of the box" experience in their distributions until H2'2012 anyways due to varying release schedules, most distributions not updating their graphics stack post-release, etc. Basically, it will still be a while.
In his last post at the time of publishing this article, he talks about IOMMU and the Southern Islands hardware accessing the main system RAM.
Thanks, as always, John for the continued feedback and engagement with the Linux community via Phoronix. It should certainly be an interesting 2012 with the emergence of the Southern Islands open-source driver support and hopefully seeing compute support working on Evergreen/Northern-Islands/Southern-Islands via Gallium3D Clover. Ideally we will also see the Radeon driver catch-up in supporting OpenGL 3.0+, power management, and other currently missing open-source features.
Lastly, hopefully AMD or one of their AIB partners will be sending out a Radeon HD 7970 soon for some Catalyst Linux driver tests and the open-source stack... In the meantime, if you wish to find out more information, drop by the forums to read the words of Bridgman and other open-source GPU driver developers.