Things have been busy in the last few weeks (in roughly chronological order):
- fed lots of PCI fixes to Linus
- mostly finished porting the kernel modesetting bits into xf86-video-intel master
- fixed lots of gfx bugs
- hacked on GTT mapping for GEM
- argued about the upstream DRM development process
- worked to close the gap between upstream DRM and current DRM master trees
- released 18.104.22.168 of xf86-video-intel (first test release for 2.5.0)
- …and various other bits of Intel internal work
Got lots of good PCI stuff upstream this merge cycle. Mostly hotplug and PM related. Just drained the last couple of regression fixes on Monday, so things should be in pretty good shape for 2.6.27. For 2.6.28 there are bunch of random cleanups & fixes queued, and I’m trying to find time to review TJ’s PCI address space code; there’s a lot of room for improvement in what’s currently upstream, so I’m hoping his stuff will help.
The 2.5 release is shaping up to be an aggressive one: we’ve already merged both GEM and kernel mode setting support into the tree along with a slew of bug fixes. Neither of the new features is available by default, but if you have a suitably capable kernel you can try them out and report any bugs we’ve introduced.
The bug queue on the 2D side isn’t looking too horrible, and the blocker list looks manageable. The first test release went out on Monday and I don’t think I’ve heard of any new issues specific to that release yet, so I’m fairly happy about it so far.
Since both GEM and kernel mode setting are really kernel features, I’ve been spending a lot of time in the DRM tree lately. In order for kernel mode setting and GEM to work really well, we need a way to map GEM objects using their GTT address, rather than the backing store physical address. Given that we’re doing this from a module using an ioctl, it’s a little tricky, and we also need to handle invalidation when the object is kicked out of the GTT and faulting for when it gets accessed again. This was one of TTM’s strong points, but we were hoping to get away without having to do it with GEM. Unfortunately that’s not the case, and it really needs to be done to make kernel mode setting and UXA possible, so making it work is at the top of my list at the moment.
On the process front, things are looking really good. The first step in fixing a problem is admitting that it exists. After some heated arguments on IRC and dri-devel it looks like people mostly recognize that the current DRM development scheme doesn’t isn’t very good at getting code into upstream kernel releases and ultimately out to users. Dave has proposed a new process (see this wiki page for the current thinking) that should make it much more obvious which bits are going to head upstream and which aren’t. It should also make sync’ing with other OSes easier since development will be more transparent, and hopefully occur on the mailing list a bit more than it has in the past, where developers typically just pushed stuff into the DRM master tree and hoped Dave would do the hard work to get it upstream.
There is a downside to the new process however. In the DRM (and in particular in the i915 driver), features have been accumulating for a long time, causing the diff between upstream Linux and DRM master to grow over time. So I’ve been working to narrow that gap and push mature features into the drm-next branch so that they’re ready for the 2.6.28 merge window. The i915 driver has had quite a few features not present upstream for a long time now, like pipe/plane swapping support, vblank rework support, page flipping, and a few other changes & bug fixes. Once these changes get upstream OSVs will start to pick them up and users will start seeing the benefit of the new development model. I’m not sure what’s happening with other drivers; several of them (like radeon) have similar issues, and some aren’t upstream at all (like XGI and mach64, among others), so someone will have to step up to do that work.
Overall it’s an exciting time in Linux-land; it’s really good to see so many improvements come together and get into the hands of users. Hopefully over time the lag between feature development, bug fixing and getting stuff to users will shrink even more.
We’ve been working furiously to get everything merged for the next xf86-video-intel release. Eric has been working to get the new GEM subsystem merged into 2.6.27 (though it looks more likely that it won’t get in until 2.6.28), Keith has been hacking on a UMA X acceleration architecture to play with some ideas about acceleration with GEM, and I’ve been working on merging things into the master branch of xf86-video-intel, along with getting modesetting-gem in the DRM tree into shape for a upstream kernel push.
As of this week, the drm-gem branches (in xf86-video-intel, mesa and drm) are no more, everything is in master now. This means that with a suitably capable kernel, you can run the latest bits and get all the GEM goodness you’ve been craving. With that out of the way, I’ve been working on porting the old, intel-kernelmode branch into master. I’m pretty close to actually getting X up and running now using the modesetting-gem bits of xf86-video-intel and drm, but I still have a bit of work to do in the EXA prepare/finish access routines. Related to that, I’ve been adding GTT mapping support to GEM, so that 2D fallbacks don’t suffer too terribly (hopefully I can figure out a way to map objects into tiling fence registers as well for even better performance). That work is totally untested at this point though; I’ll get things running slowly first, then finish the new mapping function and try it out.
Next week I should be able to finish that merge, get things running, put together a PCI pull request for Linus (there are some good bug fixes in my queue that really should have gone upstream a week or two ago) and fix some gfx bugs. After that I hope to have a look at the PCI allocation stuff. If we can get that right, 2.6.28 may be the release that gives people a lot more address space for their PCI cards, meaning everyone can use more devices and will see fewer, mysterious “resource allocation failed” messages at boot time.