I scrapped the talk before I learned that I couldn't show up, as I didn't think it was really that important. There's not a lot left to torch. Still, I did want to talk about a couple points in the graphics stack where the code in question is just rotting away slowly.
I was going to talk about XAA and EXA, but that's already been done on the ML prior to XDS. The consensus was pretty simple: XAA is still needed for older chipsets. EXA makes two demands that older chipsets can't satisfy: Heavily variable-stride allocations, and lots of compositing with alpha, using 3D engines. Also, XAA still does lots of CPU->GPU stuff, while EXA does GPU->GPU stuff. (Un)surprisingly, XAA comes out ahead in a lot of tests. Even worse, things like UXA may be necessary in order to squeeze the most out of any given chipset family, meaning that we may have to splinter the acceleration hooks in order to get good performance from each driver. Things like Gallium may save the day here; Gallium can plug in EXA from a pipe driver, and (at least according to the Gallium devs that have tested it) it kicks the crap out of the handwritten EXA code for i915 and r300.
So, summary: Nothing to nuke there.
The Mesa driver cleanup from last year appears to have been completely successful. There are a couple drivers still not under active management (mach64, mga, tdfx, and savage, IIRC) but that's alright, because they appear to still get tree-wide build fixes and that's apparently enough to keep them working. The radeon team would love to remove r300 and r600 from the classic DRI driver selection once we're sure that there's nothing left that hasn't been picked up in r300g and r600g, but this is complicated by the distros which have deployed r300 and r600 widely already. We'll need to coordinate with them for this. Main Mesa probably should drop whatever legacy GLSL parsing code still remains in favor of the new compiler, which is really maturing into a complete replacement. Gallium's growing pains make it essential that we drop dead code as soon as possible; there are a few auxiliary modules that go unused, and the failover driver is starting to rot.
Incidentally, there's some code I wanted to bring into the Mesa tree, from the various projects that have started to use Gallium in their OS offerings. AROS, Haiku, and Syllable all have patches that I'd like to pick up at some point.
Summary: We could probably remove a couple things from Mesa. Old GLSL code, r300 and (soon) r600; and failover.
On the kernel side, there are craploads of FB drivers. Most of them don't have dedicated maintainers and don't really get much love. Bringing them over to KMS would be great, and result in a lot of code cleanup, but the costs are pretty evident: (1) Code has to be written, in non-trivial amounts (2) Nobody has the hardware for some of these old chipsets (3) Deprecation times mean that the old FB drivers have to stay for a long time (4) Nobody really wants any improvements in this area, because status quo works well (5) Since nobody has the hardware, nobody's going to pay for this, so it will have to be driven by amateurs and Copious Spare Time. Things like radeonfb still are better than radeon at doing PPC-based stuff. KMS is most useful for the chipsets that have unconsolidated or buggy-by-design code. For example, mga (Matrox G-series) has code for dual-head. Except it's not in the X driver, or in the FB driver. No, it's in mplayer. A KMS mga driver that correctly sets up both heads, and handles the weird tiling setup, would be an instant win for all twelve of us in the world with these chipsets. tdfx can't do DRI on a default-depth X server. Some intrepid soul could remedy this with DRI2. (This stuff is all written down at http://corbinsimpson.com/cst, by the way.)
Summary: OH GOD KILL IT WITH FIRE but not now, how about in a few months when I have some time?
I think that's just about it. There might have been something else, but I can't remember what it was.