Another quarter, and another release. I think we've made big progress here. One of my favorite reports on the mailing list was that a company deploying our graphics driver was delightfully surprised that their XV tearing issues were fixed. That was a lot of work, and I was despairing of them saying it didn't work out.

A few things I was involved with that I'm happy with:
- Fixing the "memory leak" of GEM buffer objects
- Fixing quake4 and doom3 which regressed back in Mesa 7.4
- Fixing VBO performance on 915 (I don't like discouraging people from doing the right thing)
- OpenGL Performance and correctness fixes for cairo-gl
- Fixing a bunch of FBO problems, particularly on 965
- Hardware-accelerated glGenerateMipmaps and SGIS_generate_mipmap. Finally.
- Fixing many GLSL bugs on 965.
- Fixing occlusion queries (sauerbraten)
- Fixing crystalspace regression (woo supporting other open-source software developers)
- Fixing ut2004 hangs on G4x.

Already, things are looking exciting for our next release. Thanks to cairo-perf-trace, I've just landed a 10% improvement in firefox performance for UXA. We're also working towards the future with cairo-gl, which I'd started doing in my free time based off of ickle's cairo-drm work, and is now merged into cairo master. This is a major step towards maintaining one driver (OpenGL) per chipset, with the other part being doing a real X-on-GL backend so that legacy stuff not using cairo doesn't suffer too badly. Both of these are now on our plates for work activity in the next few months.

But we've got a ways to go to get there. I know we've got fixes to be made to our OpenGL before cairo-gl's going to shine, and cairo-gl needs a lot of work as well:

[ # ]  backend                         test   min(s) median(s) stddev. count
[  0]    image             firefox-20090601   92.877  108.208   6.54%   15/15
[  0]     xlib             firefox-20090601   46.609   46.832   0.28%    6/6
[  0]       gl             firefox-20090601  238.103  238.195   0.35%    5/6
(tested with master of everything on a 945GM, lower is better)

One of the things we need to figure out is what sort of shader support cairo-gl's going to be based on, and what we want to do in our driver to support it. The 915 and other hardware of that era can't do dynamic flow control, so many GLSL shaders would be unimplementable. But we as developers of software targeting GL on these chips would love to write in GLSL instead of ugly ARB_fragment_program and ARB_vertex_program, even if we know we can't use some language features. We could maybe expose the GLES GLSL extension on 915, which explicitly says that programs with dynamic flow control and other features missing on this generation of chips may not compile. We could also be sneaky and do it on desktop OpenGL GLSL and be within spec (I think, and afaik some closed vendors have done it as well), though some apps might get angry with us for doing so. This is up in the air, but I'm hoping our answer is "expose it".

(Oh, and other people are doing exciting things, like jbarnes and mjg59 making big power savings, but I'll leave blogging to them)