So I suppose Q&A time...
1) What does this driver support?
This driver adds atombios support to the current radeon driver. This enables the use of R500 and R600 cards with the current radeon driver. It also uses some atombios functionality on r400 cards.
2) Does it do 2D acceleration?
It provides 2D acceleration both XAA/EXA on r500 cards, and no acceleration at all on r600 class cards. The DRM supports CP (command processor) acceleration on R500 cards (need to add pci ids) which should make the r500 work the same as r300 for 2D acceleration.
3) Does it support 3D?
Not yet. I'm hoping to get some time or someone with some time in the community to port the r300 driver to r500. I've already done an initial patch to the mesa 3D driver to get the framebuffer address correctly, but not even the trivial clear demo draws anything yet. But the r5xx 3D engine is very like the r3xx 3D engine so I suspect it isn't going to be a major effort. I'd like to have compiz on r5xx sooner rather than wait for ever. R600 is not going to be supported anytime soon as it has a completely new 3D engine which requires a new driver from scratch.
4) What about modesetting?
So with Alexs help we've integrated some code from radeonhd to talk to the atombios and calculate the PLLs for these cards. Thanks to SuSE for this work. We are missing one bit where we parse the r600 object tables but this is coming soon, just need to get some time for it. So on r500 we should have full DDC and BIOS parsing support mostly, but for r600 you might find the outputs don't light up yet or DDC doesn't work. I'm also working on the r600 memory controller setup with some info from AMD that was missing from the official docs. We support randr-1.2 interfaces we just need a lot of testing to confirm things work. We also support dual-link TMDS outputs, which I've tested on ajax's 30'inch rigs. On r400 we now support driving the external TMDS chips used on some cards due to the atombios code.
5) Why not radeonhd?
Alex and myself wanted to explore using atombios to drive the card with randr-1.2, as this is what fglrx and ATIs windows drivers do. Having shared code for this area means we should be able to setup stuff exactly like fglrx so if they have a problem we have as well, but we can also use the fact that they fix problems for fglrx/windows drivers a lot more often. At the time radeonhd didn't want to use atombios and didn't have any inkling of randr 1.2 support. I hear randr-1.2 is in the pipeline now but they are against using atombios in any form for actually driving the cards outputs etc. Also when I wrote my driver a few years ago it was a branch of radeon and I really wanted to enable 2D and 3D acceleration on r500 as quickly as possible which I realised meant leveraging off the radeon driver which has DRI and accel support.
6) Future directions?
Well we are going to work with AMD/SuSE to see where we can go next. I'm currently working with AMD to get enough info on the r600 released so we can do 2D acceleration for it using microcode emulation. As the r600 has no regular 2D block we are going to have to init the basics of the 3D engine and use some pre-packed shaders to do 2D accel. These are most likely to be initially just blobs we program into the card. R600 accel will require DRM support also so we will need microcode for the r600. For the r500 3D acceleration should be at least playable with for developers.
So I've been quiet on the r5xx/r6xx scene since joining Red Hat due to the legal issues with that hardware and a previous NDA I was under. So last week Red Hat and AMD finally agreed on the strategy and am now allowed work on supporting this hardware in public.
I'd like to thank Red Hat for allowing me some time to work on this in between all the other time they let me work on upstream software. Hopefully the customers who care about this will be happy with the result :-), thanks to Alex for working on this for the past few weeks undercover while I've been waiting for legal clearance from RH/AMD legal, thanks to SuSE for releasing radeonhd code and figuring out some of the more niggly aspects of the cards in the PLL setup and the initial atombios interface code. Thanks to AMD for this process of opening up things, when they asked me to advise them on how best to do this 6 months ago I never thought they might actually listen ;-)