Up to this point AMD's open-source initiatives have always lagged behind the development of the next-generation ASICs and the proprietary Catalyst driver development. Since the wonderful time back in September of 2007 when AMD announced their open-source strategy and initially partnered with Novell to develop the xf86-video-radeonhd driver for R500+ GPUs, they've been in a constant game of catching up to supporting their latest products.
Even with the recent Radeon HD 6000 series launch, the open-source support has been months behind the product's first availability. This has been due to AMD's limited open-source team (largely Alex Deucher and John Bridgman at AMD, David Airlie at Red Hat, and the community of contributors) still bringing up support for previous generations of Radeon graphics processors. But now that the new foundation is in place with kernel mode-setting, DRI2, and Gallium3D, the pace of development is going faster. With future hardware they're also foregoing any UMS and classic Mesa support. The Radeon HD 6000 series support was behind (and most recently with a delay on the Cayman-based Radeon HD 6900 series), but the open-source Fusion support was on time and their fastest turnaround time yet (aside from when bringing up new minimally-modified ASICs have just required adding in new PCI IDs due to AtomBIOS concealing the rest, etc), but it's broken right now.
Besides having just a small team to develop the open-source driver code, as this is an official effort by AMD, the code needs to clear technical and legal reviews. Documentation created for the public open-source community is also now created after that initial open-source code is written, which in turn is derived from AMD's internal documentation pool. John and Alex have found it faster to do the code first and documentation second, in order to properly understand how the given GPU works, whether the internal documentation is accurate, and what documentation is actually useful and needed by the open-source community to further develop this code-base.
Besides the fact of getting code for new hardware support out there, it's often another several weeks or months until it becomes available to most Linux desktop users via package upgrades or when new distributions are released with the updated stack to provide a pleasant "out of the box" experience. With more of the graphics stack having moved into the kernel, it's just not a matter of pushing out a new user-space DDX driver and Mesa, but it's tied to now replacing your kernel, which is where this discussion has fit in with the recent problems of the Linux kernel DRM.
Right now it's basically six months -- or more -- from when a new generation of AMD graphics processors are released before you will find proper open-source Linux support widely available. Since 2008, for their proprietary Catalyst driver, it's basically been same-day/same-month support. The Catalyst driver is also much easier to install/upgrade for end-users on Linux distributions than the open-source drivers since the binary blob replaces most of the graphics stack with its own code, rather than relying upon the individual kernel, Mesa, DDX, and libdrm all being bumped and upgraded separately.
It's been three and a half years now of AMD working on this open-source Linux support, but they're almost at a turning point. John Bridgman wrote in the forums, "Now that development is mostly 'caught up' with new hardware development (at least we're starting less than a year after the proprietary driver team now) we're trying to piggyback open source design & planning onto the proprietary driver work. We won't be able to do this fully for the next generation of parts but hope to be in sync after that."
Bridgman further clarified, "The 'next generation' is the one we aren't talking about yet, other than acknowledging that we are in fact continuing to design new GPUs :D We were not able to start at the same time as the proprietary driver folks for that generation but at least they are still working on it. The generation *after* that is the first where we are able to design & plan the open source support at the same time as the proprietary driver support."
To avoid confusion, in the product names this important moment should be the "Radeon HD 8000 series" assuming AMD doesn't change their branding scheme. "Marketing names get picked pretty late in the game, but if the same pattern holds then we're starting to look at what you would call hd7xxx but that's still almost a year behind the earliest proprietary driver design work. What you call hd8xxx is the first generation where we can start open source driver design efforts more or less in sync with hd8xxx. They could end up being called something completely different from hd7xxx and hd8xxx, of course."
From Bridgman's comments, which are always worth reading and he is in fact the most active individual in the Phoronix Forums with nearly 5600 posts, it's with the GPUs two generations into the future (Radeon HD 8000) where open-source driver development at AMD will finally happen in tandem with the closed-source driver.
At that point, hopefully we will be greeted by near same-day open-source support, maybe even documentation too. Intel is to that point already with their IGPs for having open-source code available (not necessarily within the latest distributions at launch time though), but it's not without some hiccups and other early adoption issues.
AMD's next-generation (Radeon HD 7000 series) will be launched this year, which will hopefully have less of a slowdown in delivering open-source support, but it will not be until next year that the generation to follow that "Radeon HD 8000 series" will launch. Let's just hope AMD doesn't make any adverse changes (or that they would go the way of VIA) to their open-source strategy.
Granted, it's been since late 2007 we have talked about future AMD GPUs becoming more open-source friendly based upon comments from Bridgman. In particular, future revisions of AMD's Unified Video Decoder (UVD) becoming more modular. This is sought after since up to this point AMD has not provided any code or documentation for their UVD unit as they are still investigating whether with UVD1/UVD2 that would put their Digital Rights Management protections in a compromising position on other platforms. A more modular UVD architecture would allow the video encoding/decoding engine to be documented and supported in an open-source world without potentially borking the Digital Rights Management abilities. The "Radeon HD 8000" would be fantastic for the open-source user if it also brought such a redesigned video decode/engine engine.
For now though there's still plenty to be done besides dreaming of the day of same-day open-source KMS and Gallium3D support. You can be supporting AMD with your hardware purchases and working on the open-source drivers yourself. Even if you're not an experienced developer, there's still valuable contributions to be made in terms of testing, documentation, etc. Ask on our forums if you're looking for ways to get involved.
Next year the Mesa / Gallium3D support will hopefully be in much better shape -- especially if video decoding and OpenCL state trackers are working this summer and OpenGL 3/4 support manages to appear -- where the open-source drivers are of relevance to more users.