The way I understand it, they are interested in GPGPU research, not in implementing some state trackers, and their contribution to the open source stack is just a side effect of this.
There is no one wasting resources except for the volunteer contributors, who might be wasting their time that can be spent elsewhere, you know, by actually making some money.
Wait, you're saying that I can't reserve the right to demand that other people donate their free time (or research time) working on projects that I want them to work on? NOO!!!!
In my case it's more that I am hoping that the OpenCL state tracker gets finished so that my proposed thesis project is usable by the gallium infrastructure...
I'm currently thinking about proposing an OpenCL port of the VP8 codec, which would mean that any OpenCL-capable system could accelerate decode of this new format. Of course, if I don't get any advisors to bite on that, I could try to directly do a VP8->Gallium state tracker... or fall back to something work-related... or try to finish the OpenCL tracker myself.
Just because you can't do it does not mean that others are as incompetent as you are.
I can use OpenCL with ATI cards and AMD (and Intel via AMD) CPUs as I can with Nvidia GPUs. So don't make things look bad while they aren't.
They're comparing the results with desktop use for a driver that's intrinsically written to support Workstations doing things like CAD and GPGPU stuff for compute clusters and by happy happenstance does more. I just wish the "more" was more robust than NVidia's "more" because they're doing their drivers for the same reasons and just have a less stringent GL stack than AMD has right at the moment.
It should be noted that many of the "issues" are less issues and more due to things like VSYNC being off by default on Linux, faintly (or even RADICALLY so in some cases...) off GL code, and the like.