Virtuous blogs jbarnes' braindump


English (US)   back from drinking island  -  Categories: Announcements [A]  -  @ 03:45:13 pm

It’s been an exciting few weeks since my last post (well ok 6 weeks):

The downside of the KMS merge is a boatload of new kernel bugs :p but that’s to be expected. We still have quite a few 2D bugs open and those will start to migrate over to the kernel side as more and more people use the code. I’ve got some cleanups to the libdrm doxygen markup as well, but nothing I’m ready to push out (it seems there’s always a more important bug or feature to work on so docs keep getting delayed, so dear lazyweb please write it for me etc etc).

On the home front things have been fun too; my new office (a shed in the back yard I’ve been remodeling) is nearly ready to move in to, just a few more weekends worth of work to go. It’s been a fun project, but I’m really ready for it to be done now, since I need the space and freedom from distraction it should bring. The holidays were great as well. Our little family visited my parents for the week of Christmas and had a lot of fun with the clan (grandparents, great grandparents, aunts, uncles, cousins from all over came to visit). Then for new year’s my sister finally got to visit us up here in Arcata.

Well anyway, back to herding PCI patches and fixing up the KMS bits.


English (US)   reflecting on releases  -  Categories: Announcements [A]  -  @ 11:46:00 am

Releases in graphics land

I’ve spent a lot of time recently getting some fairly ancient pieces of work pushed up stream, and it got me to thinking about how quickly we push new code upstream in the DRM, xf86-video-intel, Mesa and X server trees.


My primary interest lately has been the DRM tree, where two of the big features I’ve helped create took way too long (IMO) to land on actual user machines. So how have we done there?

2.6.27..today6346 files changed, 7894 insertions, 2132 deletions
2.6.26..2.6.274994 files changed, 58047 insertions, 0 deletions (tree moved to drivers/gpu)
2.6.25..2.6.263829 files changed, 2937 insertions, 1335 deletions
2.6.24..2.6.254763 files changed, 2721 insertions, 956 deletions
2.6.23..2.6.241765 files changed, 2388 insertions, 3153 deletions
2.6.22..2.6.232777 files changed, 2609 insertions, 2528 deletions

Honestly, I expected to see more quantitative evidence of the qualitative changes we’ve made recently, but maybe that’ll take awhile to show up in the stats. The real issue though is the disparity in commits to the DRM tree vs. what got merged upstream: there were 1165 commits to the DRM tree in the timeframe above, including fairly infrequent libdrm changes, while the kernel only saw 241. At a high level that would seem to indicate that we did a pretty poor job of keeping the upstream kernel up-to-date, at least until recently.


For xf86-video-intel, I think things have been pretty good since we started doing quarterly releases. Our time based schedule means that users get new features and bug fixes in a fairly timely manner, though there occasional exceptions like feature trees that don’t get merged for a long time, if ever. For example the batchbuffer and kernel mode setting branches never got merged (though support for those features ended up in master anyway in different forms). We’ve been doing this for long enough that I don’t think commit stats would mean much (though it would be intresting to plot commit counts over time along with bugs reported and fixed I’m not going to do that today).


Mesa tends to see a lot of churn since it includes both the core 3D engine (and Gallium too these days) and all of the supporting drivers. Its release schedule isn’t as predictable as the kernel’s or xf86-video-intel though, which makes it hard to know when a given fix or feature will end up in the hands of users. AFAICT it operates on the “when it’s ready” release schedule, which is good and bad. Releases tend to be stable and long lived, but new features and fixes sometimes take awhile to get out. This is why for Intel we end up doing branched releases of Mesa every quarter so our latest driver fixes are available to distros and users right away. Any changes to the way Mesa works would probably need more developer time, which is fairly scarce in the open source graphics world, so I don’t expect this to change anytime soon. (I didn’t dig through the Mesa logs to see how things are here, so dear lazyweb etc.).)

X server

What can one say for the X server itself? Let’s see how frequent those releases are:

xorg-server-1_1_0May 22, 2006ajax
xorg-server-1.2.0January 23, 2007ajax
xorg-server- 19, 2007keithp
xorg-server-1.4September 6, 2007anholt
xorg-server-1.5.0September 3, 2008ajax

Releases have been all over the place, from about a year apart to a few months, with correspondingly inconsistent release tags. I think this reflects both a lack of developer power and lack of clear ownership for the X server: no one person or organization “owns” the X server enough to make sure releases happen frequently, and getting people to fix server bugs for a given release is like herding cats, so release managers end up with the herculean task of doing everything themselves. Personally, I think pulling the drivers back into the server module would alleviate this somewhat, since it would give driver developers an interest in making sure the server is in good shape, and probably also induce them to work on server features and bugs so that releases could happen on a regular schedule. Very few people share this opinion though, so I’m not hopeful that people will agree to it anytime soon.


English (US)   random update  -  Categories: Announcements [A]  -  @ 07:55:57 pm

kernel mode setting requirements

I’m hacking on getting the core DRM mode setting code ready for merge this week, along with the i915 code, but I’m not sure if my posts made the requirements for testing clear.

I posted a patchset for core, i915 and radeon mode setting to the dri-devel list recently, but there are a few other patches required in order to test those bits (which btw are very raw; I was able to get a root weave from X but things were pretty crashy if I tried to rmmod/insmod the module again). Anyway, if you want to live on the bleeding edge, you’ll need my xf86-video-intel EXA pixmap patch, and my libdrm &amp drm patches for GTT mapping.

Note that we don’t currently track per-pixmap tiling, so you may have to disable tiling in your xorg.conf to avoid corruption (either that or force every pixmap to be tiled in i830_exa.c at map or creation time).


English (US)   GTT mapping 101  -  Categories: Announcements [A]  -  @ 11:40:26 am

xf86-video-intel 2.5.0

Well, xf86-video-intel 2.5.0 is out finally. About 3 weeks later than we would have liked, but at least we got most of the blockers (nearly all of them in fact) fixed and stabilized the 3D side of the release. As I mentioned in the release announcement this release includes lots of new code and puts us in a good position to really improve EXA and support kernel mode setting quickly.

GTT mapping & pixmap management

One of the things that GEM enables is improved memory management in the 2D driver. In the past, the 2D driver statically allocated several chunks of memory for use by various GPU structures, 2D pixmaps, the front, back and depth buffers, and 3D textures. Needless to say this was fairly inflexible. With GEM in place, most of those static barriers have been eliminated, with the exception of the EXA offscreen pixmap area. Fortunately, EXA (and its close relative, UXA, which is also part of the 2.5.0 release) allow the driver to manage pixmaps if desired. So following the 2.5.0 release I started hacking on the driver to do its own pixmap management. In order to do this well, however, EXA’s PrepareAccess hook should map pixmaps through the GART using write combined access, since the alternative is to map the actual RAM backing store of the GEM object and flushing the CPU caches at FinishAccess (turns out this is fairly slow). This, in turn, means that the kernel needs to allow mapping of objects through the GTT aperture of the CPU’s address space. The patches to allow that are fairly complete at this point, and even include fence register allocation & setup for mapped objects. This should allow us to tile our offscreen pixmaps at some point (fairly soon on 965, and with a little more work on pre-965). As long as we don’t fall back to writing the objects with the CPU very often (thus putting pressure on the limited number of fence registers available and incurring page faults) this should be a performance win.

Kernel mode setting

All of the above is also required for kernel mode setting to work. In a KMS world, the kernel will be allocating a front buffer and will expect the 2D driver to use it for all memory management and fence register allocation. Now that I’ve got these pre-requisites working fairly well, I’ve been able to revisit the KMS code and fix it up in preparation for merging into 2.6.29. Yesterday I fixed merged the latest bits from the drm-next and drm-rawhide branches into the drm-rawhide-intel branch and got a root weave going with a slightly tweaked 2D driver. I should be able to post the required patches this week and get them cleaned up for merging (hopefully next week, assuming the GTT mapping stuff goes in).


English (US)   back from ks/lpc...  -  Categories: Announcements [A]  -  @ 08:47:58 pm

Only to be greeted with a leak in the water main from the street to my house. Nothing a few trips to the hardware store, some digging, gluing and clamping couldn’t fix though (my patch has been holding so far at least). Hopefully next month’s water bill won’t include over 20,000 gallons of leaked water…

But I digress. Plumbers turned out to be a great conference. Kristen & co. had some ambitious plans for the event, but they didn’t disappoint. The conference was extraordinarily informative and productive, with many of the “talks” being more like working sessions, where everyone shared information and fixed or solved problems on the fly. The highlights for me were the Audio, Boot and Graphics tracks.

At the Audio track I learned a lot about how ALSA works from Takashi-san; I think we all agreed that some of the ALSA bits should be pushed upstream a little more aggressively, to support new hardware and fix configuration problems. Also I got Lennart to promise me that mixer settings would suck at least 100% less in future versions of Pulseaudio, which although better than straight ALSA is still lacking in some areas. There was also some discussion of adding virtual output devices to the ALSA library plugin API. I think this makes a lot of sense, since when I associate my bluetooth headset I want to be able to see it in application drop downs immediately.

The Boot sequence track was interesting because we got to see a demo of Arjan & Auke’s work to reduce boot time to 5 seconds on an Eee PC running Moblin. Some of their work was added to Fedora and Ubuntu immediately following the talk, and if nothing else I think they’ve given the distros something to shoot for. Dave and Kyle talked a bit about initrd and startup services; hopefully we’ll see some unification (mkinitrd in the kernel tree basically) sometime soon, assuming Dave makes it home.

Maybe I’m biased, but I thought the Graphics track the most interesting. Dave and I started out with an update on the kernel mode setting work. I demoed panic under X (and it worked!) and got some applause, which was nice. Most of our time was taken up with an argument with Linus about our development process, however. The discussion went something like this (paraphrasing here):

Linus: “You guys are idiots, you should have developed this incrementally and pushed it upstream a long time ago”

Us: “No, you’re a pinhead, we’ve done the incremental development and this is where it took us. We’ll be pushing upstream soon now that we have APIs we can actually support.”

Linus: “No, you guys don’t get it, you should have done the development like this, x, y, z”

Us: “Oooh, we see what you mean now. Yeah we tried that, it sucked real bad.”

Linus: “You’re dumb.”

Us: “Well you’re a pinhead.”

And then we agreed.

Ultimately, after some offline conversations I think we came to the conclusion that yes, developing out of tree for as long as we have sucks, but on the other hand there aren’t any great alternatives with sane kernel APIs that we can support along the way. All of this means that we should see kernel mode setting upstream soon; even if it’s not fully cooked the interfaces are in good shape so all that’s left is bug fixing.

The other topics we discussed were interesting too: Carl went over what happens when you try to draw text to the screen, and all of the ways it can end up being slow (which it has done for a long time now with EXA), then Jaya talked about some of the unique aspects of E-paper graphics support. It was a really interesting topic, with some unique problems (some of which we found solutions to on the fly during Jaya’s “open issues” time). Ian concluded with an overview of OpenGL 3.0 features and what it’s going to take to get Mesa to support them. All in all, good stuff and a great conference.

But with all of that out of the way, it’s back to the hard work of getting GEM, kernel mode setting, and GTT mapping merged, along with fixing bugs in xf86-video-intel prior to release, managing the PCI queues, and doing some power on work for an upcoming mobile platform. No problem.

powered by b2evolution free blog software

Contact the admin - Credits: multiblog | green power hosting | test