AMD has yet to go through their final intellectual property review on the R600/700 3D documentation that could yield open ATI R600/700 3D graphics by Christmas (though the chances of this happening are slimming), but Novell's Hatthias Hopf has provided a status update to report that they have internally begun work on an RV770 DRI driver for Mesa. Matthias and Alex Deucher have now been successful in running r600_demo (a very basic 3D test program) on the RV770 GPUs (Radeon HD 4800 series) in the same way as the Radeon HD 2000/3000 series. The Hopf-Deucher duo along with the two other AMD engineers that report to John Bridgman have started work on the Mesa DRI driver that will allow open-source OpenGL acceleration for these new ATI graphics cards. As no documentation or code has yet to be cleared by AMD's legal department, all of this code is being worked on privately...
The exciting times will be when Larabee is out, and you can throw these fixed functions cards away, and actually use your card when you buy it (rather than one year later, and only if the manufacturer feels like it). I ditched NV for AMD, looks like I'll be moving to another manufacturer again
Just to be clear; this is a bog standard Mesa/DRI driver, right? Not one for Gallium? If so, what's the rationale for not skipping straight to Gallium? That would seem like the thing to do to me, though I obviously don't know what I'm talking about.
First release will be Mesa using the existing driver model, ie making a copy of the existing r300 code (which handles 3xx-5xx) and modifying it to use 6xx/7xx sequences instead of 3xx/5xx. We also plan to use the existing ioctls for communication between mesa and drm, not the new improved ones being worked on by Dave, Jerome and others.
The purpose of the first release is to get working code into users and developers hands and to find out any hardware-related issues as quickly as possible. Going with "known good" (and I use the term loosely because all of the developers agree that the current code is old and crufty) simply lets us focus nearly all of our efforts on hardware-specific work without having to also deal with changes and issues in the new code.
Once we have working code for the existing driver model it will be easy for the developers to re-use that code with the Gallium driver model and/or the new command submission, fencing and memory management code.
Put simply, going this route lets devs come up to speed on Gallium and other new things in parallel with us coming up to speed on how to make the chip work. I think it gets us where we want to go in the fastest and most predictable way.