Ubuntu X.org maintainer Bryce Harrington responds to Brainstorm Idea 2978:

Brainstorm 2978 and its comments detail problems with the level of support and quality of available open and proprietary drivers for AMD/ATI hardware. The desire is to have Canonical work more closely with AMD/ATI engineers to change this situation.

The short answer is this: AMD/ATI engineers have recently started working with us on both -fglrx and -ati issues, and I anticipate seeing significant improvements in this driver for Intrepid.

Keep reading for a lot more background and detail.

As of the Hardy release, the -ati driver had more total bugs reported against it than any other single video driver. -fglrx was better in this regards but also has a long history of quite severe bugs which were hard to do anything about due to it being closed-source.

Several of the things said in brainstorm 2978 are no longer true with the latest versions of the drivers, or exaggerate issues, but the general point that the drivers available for this hardware are buggy compared with other drivers is a certain truth.

There are currently three drivers available for AMD/ATI: -fglrx, -ati (aka -radeon), and -radeonhd.

fglrx

-fglrx is a binary, closed source driver created and maintained using a proprietary style software development process. In some respects this model produces good results, in that the company can put huge resources on problems that are critical to important big customers. However, in the Open Source world most ordinary users are far from being "big customers", so there hasn't been a way for their issues to be heard and dealt with. I suspect this is the main cause for most of the frustrations people have had with -fglrx, and while many of those problems have since been solved, the frustrations tend to stick in the memory.

The good news is that due to increased interest in Ubuntu by OEMs, AMD/ATI is now working with us and paying attention to -fglrx issues affecting Ubuntu users. I can't yet point to specific fixes that have resulted from this relationship, but I can say that the situation has changed 180 degrees from where it was a year ago.

AMD has also adopted a monthly release schedule for their driver. That is a decent compromise to open source drivers (where us distros could take a snapshot or cherry pick patches whenever we see fit). The downside is that SRUing an entire new driver (with no way to examine the code changes) is more risky than our SRU policies can tolerate. However, for Hardy we've addressed this issue by promoting use of EnvyNG. Envy was a third-party tool maintained by Alberto Milone (tseliot) for installing binary drivers, which unfortunately did not "play well" with the installed driver from linux-restricted-modules; during Hardy development, myself and several other Ubuntu engineers worked with tseliot to eliminate the inconsistencies and redesign things to make EnvyNG and l-r-m co-exist nicely. The result is that we can recommend use of EnvyNG as a semi-official way to upgrade -fglrx and track AMD/ATI's work.

A future planned change (likely for Intrepid) will be to break out both -fglrx and -nvidia from the linux-restricted-modules package.

ati/radeon

Historically, -ati was the open source alternative to -fglrx. It was a showcase example of blackbox reverse engineering of video hardware to figure out what different registers are for, and how to use them. Reverse engineering is very hard work and extremely error prone. Also, since hardware varies, it depends a LOT on the engineer having access to a lot of different hardware, testing each individually and mentally imagining what is going wrong.

For basic 2D stuff, this worked fairly well, but as you can imagine the 3D side of things (required for Compiz, OpenGL screensavers, games...) there are a lot more registers. The 3D side also tended to vary a lot more from generation to generation of hardware, and assumptions made in testing one card could be way off mark with the next.

I think a lot of the problems people are seeing are from this 3D side of things. This is one reason why Compiz was blacklisted for ATI in hardy (which is sort of a shame, because it *does* work for some ATI hardware, but we just can't predict what situations it will and won't work in, and decided we had to take the feature regression in the interests of LTS stability.)

As fortune would have it though, last fall AMD/ATI released register-level documentation for much of their hardware. They also hired Alex Deucher, one of the main -ati driver developer; providing him with better access to hardware information than the community ever had before.

Still, digesting all this information, feeding the improvements into -ati, adding support for newer hardware, and doing necessary QA takes time. Hardy got a small whiff of some of these improvements, but it really won't be until Intrepid and Intrepid+1 that I think we'll see the bulk of the improvements.

Meanwhile, Xrandr support was added to -ati, which was great in enabling its level of support for projectors and monitor hotplug, but forced some reworkings of internals that exposed a lot of new issues (some of which still exist in Hardy.)

One of the projects I'm working on is to identify fixes from the new -ati that fix distinct reported bugs or enable new hardware, and get them backported to Hardy so we can strengthen the LTS release. Along with this, I plan to put a heavy focus in -ati bug triaging and upstream reporting, in hopes that we can make Intrepid's -ati much more robust. I would love to see us be able to drop the Compiz blacklist.

I've spoken with Alex about these plans, and he's quite supportive, so I think it's just a matter of putting in the labor to get the bugs analyzed and reported upstream. I'm hoping we'll see a dent in the bug stats by Intrepid; if you have ATI hardware and a little time to help, there is a lot you can do (even if you're not too technical) to help increase the size of that dent, by doing testing and analysis of bugs. See http://wiki.ubuntu.com/X for jumping off points into troubleshooting, backtracing, and more. Like the brainstorm writer points out, lots of people have ATI motherboards and enabling X to "just work" for them could help in expanding Ubuntu to many more people.

radeonhd

The -radeonhd driver is a relatively new effort by Novell, originally focused only on the R500-class of ATI devices (which -ati did not cover as well), particularly aiming at 3D capabilities. While we provide -radeonhd in Ubuntu, since it supports only a narrow range of hardware we still consider -ati to be the official default. -radeonhd has improved a lot since Sept 2007 when it was first announced, but is still considered a work in progress. As well, since -ati interfaces to AMD/ATI's AtomBIOS it's been able to make faster progress lately than -radeonhd.

Looking forward, a hope is that -radeonhd and -ati could be merged together, which could result in a unified driver with strong support for the complete range - R100, R200, R300, R400, R500 and R600. But this depends obviously on the two driver teams...

For more discussion about -radeonhd and -ati, here is an interesting article: http://www.phoronix.com/scan.php?page=article&item=radeon_vs_radeonhd