AMD's Position On Gallium3D Support

If you're a member of the Phoronix Forums where John Bridgman, the AMD employee in charge of the open-source ATI graphics strategy, is known to frequently post (with over 4,200 comments) along with many other X.Org developers and AMD employees, you pretty much know what there is to know about their position on Gallium3D and other topics. However, if you don't, this post is for you.

In response to the ongoing discussion on the DRI development list surrounding Intel and the shortcomings of Gallium3D, Bridgman has commented from his point of view at AMD. The most interesting and important points have been highlighted.

We made essentially the same decision as you 18 months ago and implemented the initial r6xx/r7xx 3D driver on the "classic" HW driver model rather than Gallium3D. Even at the time it seemed highly likely that Gallium3D was going to work out well, but between the newness of Gallium3D itself and the work still to be done on KMS/DRI2/GEM/TTM there was just too much "new" for my liking.

We did ask one of our devs (Cooper) to help with the Gallium3D effort and also look into video decode using G3D, but unfortunately he got pulled off onto another urgent non-driver project shortly afterwards so we didn't end up doing much to help at all. Fortunately the other developers pushed ahead without us (thanks guys ;)) and it's probably fair to say that our developer focus will probably jump across to r600 on Gallium3D fairly soon as well.

For what it's worth, if we were writing a new "has to work, can't afford delays" driver from scratch today we would go with Gallium3D, period. Prior to that... I think we were confident it would all work but weren't quite sure how long it would take.

The reality is that we don't have a conveniently timed architectural break to force the writing of an all new driver, and I imagine you don't either, so we're all going to have to "ooze" across to Gallium3D. The initial code to support Evergreen (HD5xxx) GPUs is being implemented on top of the "classic" r600 driver because so much of the programming model is common, but from that point on I think we would try to push the Gallium3D code ahead rather than doing more work on the classic code base.

I'll try to get a statement from our proprietary OpenGL driver team re: compatibility profiles -- or, more to the point, deprecating older GL functionality. I haven't looked into the issue much myself but my first impression was definitely "uh-oh, this is going to be a problem for a bunch of our users".

In essence, John Bridgman is pleased with the situation overall for at least the open-source ATI graphics drivers on Gallium3D. The "R300g" driver that supports the R300/400/500 GPUs (up through the ATI Radeon X1000 series graphics cards) was started actually not by AMD but instead Corbin Simpson, which was a developer at university participating in a previous Google Summer of Code experiment. This ATI Gallium3D driver is now beating out the classic Mesa driver and is catching up to the old proprietary ATI Catalyst drivers. The new ATI Gallium3D driver that is for the R600/700/800 series ASICs is still forthcoming and is not yet in a usable state. The R600/700 classic Mesa support though is usable right now and the R800/Evergreen should be in the coming months (another tid-bit of information that can be learned from our forums). It still will be some months before the ATI Gallium3D driver for these more recent graphics cards (the ATI Radeon HD 2000/3000/4000/5000 generations) are working atop a Gallium3D stack.

What's good to note though from John's comments is that with the next-generation ATI graphics processors, they will likely be going directly to Gallium3D for their open-source 3D driver. This next-generation would be the ATI R900 class graphics processors, probably to be called the ATI Radeon HD 6000 series, but those are still a few quarters away.