They are awful. Currently, support for all R200 based cards (Radeon 8500-9250) is broken. The only solution to this problem is to use old drivers which are terribly buggy and unstable (or to use the drivers from DRI which have the same bug and sability problems).
It also took ATI nearly a year to start releasing drivers which would work with XOrg instead of XFree86.
It also irriates me that they can't even make their own version of glxgears (fglrx_gears) work properly. As far as I know, it is supposed to render glxgears to a texture and apply it to all six sides of a rotating cube. Unfortunately, using ATIs drivers, the cube is just a solid blue color. This seems to be an indication that pixel buffer support is broken.
Games generally work with some bugs here and there. However, what really irritates me the most is their general incompetence in their OpenGL implementation.
Being a developer, I expect correct code to behave correctly. It is especially difficult to deal with their lack of quality when it comes to learning something new about OpenGL and wondering where your code is wrong and why your results are bad when it is actually a driver bug.
Next time, I'm buying nVidia -- open source or not.
I can't recall that pixel buffer rendering ever worked
right on the R200s even on the Windows platform. I remember
working on a bug similar to that when I worked there in 2002/2003.
It was on an example program written by a talented
Swede, "Humus". The R200s (esp 8500) also had problems
with games such as "IL2 - Forgotten Battles". Pipeline
stalls when executing a display list. I suspect that
the problem is more than just software. R300s never had
the pipeline stall problem with that game.
If you could port Humus' demos to X/glx you might see
a patterm.