Virtuous blogs jbarnes' braindump

08/28/08

English (US)   hi my name is jbarnes and it's been three weeks since my last blog entry  -  Categories: News  -  @ 02:40:03 pm

Things have been busy in the last few weeks (in roughly chronological order):

PCI

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.

xf86-video-intel

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.

DRM

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.

Trackback (0)

Trackback address for this post:

This is a captcha-picture. It is used to prevent mass-access by robots.

Please enter the characters from the image above. (case insensitive)

Trackbacks:

No Trackbacks for this post yet...

Pingbacks:

No Pingbacks for this post yet...

powered by b2evolution free blog software

Contact the admin - Credits: multiple blogs | webhosting | paid blog