Archives for: 2008


Permalink 11:46:00 am, by jbarnes Email , 683 words, 21835 views   English (US)
Categories: Announcements [A]

reflecting on releases

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.


Permalink 07:55:57 pm, by jbarnes Email , 164 words, 13902 views   English (US)
Categories: Announcements [A]

random update

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).


Permalink 11:40:26 am, by jbarnes Email , 466 words, 28559 views   English (US)
Categories: Announcements [A]

GTT mapping 101

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).


Permalink 08:36:10 am, by jbarnes Email , 374 words, 12167 views   English (US)
Categories: News

and more travel...

And just when I thought I was done travelling for awhile… Turns out I have to spend a few days in London for top secret meetings (should be good actually but it would be nice to be home for a change).

On the plus side, GEM looks like it’s finally queued up for 2.6.28! This is huge, since we’ve all been waiting for some kind of memory manager to land for many years now. If there’s any justice in the world, Eric should never have to buy beer again in the company of anyone even slightly involved with Linux graphics and desktop development.

With that out of the way, some of the other stuff queued up behind the memory manager can finally land; Dave and I had talked with Linus about merging the kernel mode setting bits, but now that I’m out of the loop for a week or so I’m not sure if I’ll be able to help much with that (not to mention that I’m trying to fix what I hope is the last issue with my GEM GTT mapping patches, which now include fence register management, so that xf86-video-intel with GEM based pixmap management becomes viable). DRI2 should also be coming soon, though I haven’t talked with Kristian about it recently.

This quarter’s release of the Intel driver has been somewhat delayed though, despite all the good news. Trying to stabilize the GEM stuff on the 3D side took a lot of Eric’s time, but it looks like things are in reasonable shape there now. We’ve fixed a few of the more offensive 2D bugs recently too, but there are still more open than I’d like at this point, but I suppose we can always do point releases later as things get fixed up. So when a new libdrm comes out (which should be possible now that GEM is queued up and the interfaces are stable) I should be able to spin the final 2.5.0 package, completing the 2D side of the release.

Well, more later. I have to go dig up a separate machine so I can figure out what’s going on with my GTT mapping code (no kernel mode setting means I can’t see the panics I’m causing yet, sigh).


Permalink 03:33:07 pm, by jbarnes Email , 794 words, 43879 views   English (US)
Categories: News

news from the north

Finger exercise

It’s been a busy couple of weeks since I got back from Plumbers. The merge work seems to be going well; we finally got an ack from Nick on the GEM stuff, so we should be able to push that for 2.6.28. Eric put together a rollup tree with everything we’d like to push (this will probably be the busiest release for i915 since it was initially written), including GEM, several bug fixes, the reworked vblank code (which also contains bug fixes), and support for MSIs, which can save us a lot of CPU time in shared IRQ configurations. The xf86-video-intel 2.5 release is slowly coming together as well, with several bugs fixed, including some of the nastier, EXA related ones. The related 3D and kernel releases are also maturing well, so hopefully this quarter’s release will be stable and feature filled. PCI has been pretty busy too; lots of reviews to do, lots of fixes streaming in and a few new features too (still hoping to get the I/O virtualization support in before the merge window opens too). Finally, the top secret soon-to-be-released platform work is going well; I finally managed to get my bits into a state I’m fairly happy about, so I’m looking forward to seeing it out in the wild.

Graphics merging

So the GEM merge, and more generally, some kind of memory manager merge, has been a looong time coming. It looks like the wait will finally be over once the 2.6.28 merge window opens. To recap, having a real memory and execution manager like GEM enables all sorts of good features: reasonable texture-from-pixmap support for our 2D/3D stack, in-kernel mode setting, removal of user level register access from our 2D driver, redirected & composited direct rendering, and probably several more that I’m forgetting. With the kernel bits in place we should be able to merge the kernel mode setting code finally too (it’ll be disabled by default so it should be fairly safe to merge early), and accelerate our pace of integration into the kernel. That means things like improving the panic stuff I demoed at LPC to be even better, and providing some additional features and generally polishing things. Yay!

xf86-video-intel 2.5

We’ve been closing bugs at a fairly good rate recently, but I still have some concerns about our stability on G4x machines. I should be getting mine soon though so I can help with that, and Zhenyu will be back from vacation next week to finish off some of the fixes he’s been working on, so I’m confident we’ll be in good shape by the time we release. Carl, meanwhile, has been doing some good work on EXA, closing out the notorious “EXA slower than XAA” bug at long last. With a recent X server, the driver is actually in pretty good shape, performance-wise. Carl is trying to track down a couple of more issues for the release, so if you’re someone who can easily reproduce EXA problems, please add your $0.02 to the various EXA bugs; I’m sure Carl would appreciate it.

On a related note, we’ve finally been able to release the IGD OpRegion specification, which should allow distributors and developers to more easily hack on the driver to support various platform features, like ambient light sensors and hot keys. And for pre-OpRegion platforms, I’ve been trying to add more support to our VBIOS support code to at least document the various structures and handshaking registers, I hope to be able to push that work out soon, though I doubt I’ll have time to writeup a full PRM like we did for the OpRegion spec.


The PCI arena has been fairly busy over the last couple of weeks. Several people got involved in the e1000e NVRAM fire drill, including me (since the X server was initially though to be to blame, and it just so happens that I also wrote the code the X server was using to bang on PCI registers). In the course of debugging the problem, we added several safety checks to various bits of code (the PCI sysfs layer, the I/O resource management layer, the e1000e driver itself, etc.) which turn out to be generally good to have regardless. On the patch management front things have been looking good; we’ve merged several cleanups and fixes (including at least one annoying regression) in the past couple of weeks. The PCI slot naming and SR-IOV support patches aren’t merged yet, but they’ve been getting a lot of review so I hope to be able to pull them in soon (and in time for 2.6.28).

Well that’s it for now. Back to doing ‘git pull’ every few minutes to see if the GEM bits have landed yet. :)


Permalink 08:47:58 pm, by jbarnes Email , 726 words, 16813 views   English (US)
Categories: Announcements [A]

back from ks/lpc...

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.


Permalink 11:24:45 am, by jbarnes Email , 633 words, 22273 views   English (US)
Categories: News

too much travel

Sigh. Oh nevermind, I won’t apologize for my lack of posting. No excuses.

Conferences and planning

So, the past few weeks have been quite busy with travel and hacking. Early in the month I attended the X.Org Developer’s Summit in Edinburgh, Scotland. It turned out to be a very productive conference; we worked out several issues with the DRI2 design, shared a lot of good info, and spent some time planning future releases. Following XDS, I headed up to Portland, OR to meet with some of the Intel driver team to do planning for future development. As usual, there’s a ton of interesting work that needs to be done, so we’ll be spread pretty thin, but it looks like the next year should see some major improvements to all layers of the stack. I’m spending this week in Portland as well, for the Linux Kernel Summit and Linux Plumbers Conference. The kernel summit was fairly good; we even got some hacking & bug fixing done, though we didn’t make much progress (in my opinion) on fixing our procedural issues with profiling & instrumentation. Hopefully someone will step up to take ownership of those areas and get things into shape…


I’ve been careful about pushing PCI fixes for 2.6.27, partly because Linus seems really cranky about post -rc pulls these days and partly because things are actually looking pretty good. The last pull had mostly compile warning fixes (and the current queue includes a couple of those as well) but there weren’t any serious issues that would affect a lot of users to fix once the -rc came out… For 2.6.28 there are a few things I’d like to include, but I have to find time to review and integrate them; we’ll see if I manage to do that (the main ones are VGA arbitration and address space management improvements)


I sent out a 2.5 pre-release for xf86-video-intel awhile back and things have been moving much faster than I’d like since then. Eric fixed up libdrm to separate out the Intel buffer manager API into an Intel specific extension, which is good since we’ll depend on a new libdrm for this release. This ended up destabilizing things a little, but Eric (fortunately given my schedule lately) has been picking up the pieces.

On the DRM front I’ve been working to finalize the GTT page faulting code, which we’ll need for both GEM and kernel mode setting in order to handle fallbacks efficiently in the X server. We may also end up using it to deal with tiling issues. The patch is looking pretty good now (thanks mostly to reviews by Thomas and Nick), I just have one last issue to fix and hopefully we can roll the code into Eric’s GEM branch.

I’m still crossing my fingers that we can get GEM into the drm-next tree in time to get it into 2.6.28. Dave and I harassed some people at KS about the remaining GEM issues, so hopefully we’ll see an ack from Nick on lkml soon, which will allow Dave to pull the bits into his DRM tree. Once that happens, I can diff out the kernel mode setting bits and submit them. Doubtless a few bugs have crept in since I last merged things in the DRM modesetting-gem branch (I think suspend/resume broke along the way somehow) so I’ll have a few things to fix, but other than that things should be in pretty good shape. It would be nice to get this queued for 2.6.28 as well, but that’s fairly ambitious.

In all, I’ll have a ton of catching up to do when I get back home next week. But I’m still holding out hope that I’ll be able to get a little hacking in this week at Plumbers; we’ll see.


Permalink 02:40:03 pm, by jbarnes Email , 758 words, 18199 views   English (US)
Categories: News

hi my name is jbarnes and it's been three weeks since my last blog entry

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 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.


Permalink 10:05:40 pm, by jbarnes Email , 157 words, 38591 views   English (US)
Categories: news

Visiting Grandma & Grandpa

I went to visit Grandma and Grandpa recently for Kathryn & Will’s wedding. It was a lot of fun; everyone was happy to see me, so I got passed around a lot. I also got to play with some of Dad’s old toys, including his old horse. Unfortunately, he wasn’t very attentive when taking this video and didn’t catch me when I lost my balance while looking at something on the floor (and he knows I love to lean over and see what’s below me every now and then!) and so I fell right on my head! Can you believe it? But don’t worry, we had a little talk later and I told him in no uncertain terms that he would not let it happen again.

Other than that, the trip was great. I got to see my Great Aunt Lenore, Katy & Jake and lots of others.

Well, that’s it for today, write at you later!


Permalink 06:25:26 pm, by jbarnes Email , 346 words, 30638 views   English (US)
Categories: Announcements [A]

xf86-video-intel 2.5 merge status

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.


Permalink 02:28:18 pm, by jbarnes Email , 528 words, 13747 views   English (US)
Categories: News

xf86-video-intel 2.5 planning

Stolen from my post to xorg@ and intel-gfx@.

It’s my turn to handle a 2D driver release again, so I’ve been thinking about what we should include (and remove!) in the 2.5 release. I’ve created a blocker bug for the release, 16926, and I’m interested in hearing about bugs you think should be added. The 2.4 release was a bit late; I’d like to avoid that this time around, and want to do the first -rc hopefully by mid-August.

Target highlights for this release include:

  1. usable EXA support
  2. support for GEM (if supported by the currently running kernel)
  3. support for kernel mode setting (again, if the underlying kernel supports it)
  4. no more video tearing with textured video & XvMC
  5. Bug fixing
  6. removal of XAA code

See below for details.

1. Usable EXA support
Carl recently pushed some fixes that should make EXA better than XAA (finally): Assuming the users reporting performance regressions with EXA vs. XAA are happy with the changes, things are looking good here.

2. Support for GEM
The drm-gem branch of xf86-video-intel has been under development for awhile now, and gracefully falls back in the case where no kernel support is available. I’d like to merge this into master to get it some more coverage. Ideally, we’d get the Mesa drm-gem branch merged into master as well, making it much easier for people to play with GEM stuff (just boot a new kernel or
insmod some new DRM modules and restart), but the Mesa bits need a little more review first.

3. Support for kernel mode setting
Along the same lines, we’d like to make it easy for people to test the shiny, new kernel mode setting bits. The 2D driver changes aren’t hugely invasive (and they give me an excuse to clean some stuff up), so I’m planning on merging them to master, again to make testing of new kernel bits easier for everyone.

4. No more video tearing
One of our #1 complaints since adding textured video support is tearing. It seems to occur in both composited and non-composited configurations, depending on what else is going on in the system. With recent changes to Mesa, hopefully the composited case can be solved by making the compositing manager use scheduled buffer swaps (i.e. using glxSwapBuffers with
vblank_mode=3 or similar), but in the non-composited case we’ll need to make our Xv and XvMC code a bit smarter.

5. Bug fixing
Catch all for fixing display bugs, suspend resume problems, improving LFP detection, fixing SDVO bugs, etc. (there are quite a few display bugs Zhenyu & I want to tackle for this release)

6. No more XAA
Back in 2.2, we made EXA the default acceleration architecture for the driver. It obviously wasn’t quite ready back then for everything people were throwing at it, but OTOH it didn’t have some of the fundamental shortcomings of XAA. It looks like it’s finally ready though, so assuming Carl has EXA performance well in-hand, we should be able to delete the XAA code altogether (which will be nice since it doesn’t support several features and has bugs we don’t want to fix).

Please direct comments & questions to myself and the list.


Permalink 01:29:11 pm, by jbarnes Email , 835 words, 23103 views   English (US)
Categories: News

Waiting for vblank...

Will the vblank-rework branch ever be ready to merge upstream? With some recent work by Michel and myself, I really hope so.

It’s a little distressing that such a simple thing could cause so much trouble. The motivation for reworking vblank in the DRM branch was easy enough: save CPU power by turning off interrupts when possible. Not interrupting the CPU lets it sleep deeper and longer, potentially saving quite a bit of power. Getting rid of the 60 or so vertical blank event interrupts per second when they weren’t needed seemed like a logical first step, and so vblank-rework was born.

Being a good citizen in Linux land often means improving whole subsystems rather than stuffing a bunch of fancy features into individual drivers. Working that way can be harder, but it spreads the benefits wider, and improves Linux as a whole. So my efforts in the vblank-rework branch targetting the generic DRM vblank code, improving the driver APIs and making sure that all drivers could benefit from the new infrastructure, allowing them to disable interrupts when not needed. However, that’s where the “harder” part comes in: every driver needed an update. At first I thought, “Hey this is a neat, new set of APIs, surely everyone will want to use them, I’ll just convert the i915 driver (after some initial work on a radeon based laptop).". Unfortunately, the DRM drivers are in dire need of attention, so after several months of waiting I ended up converting all the drivers myself, though only a few like radeon and i915 actually implement the API fully enough to disable interrupts.

So far, so good. I figured everything was fine and the shiny new branch was ready, so I merged it into the master DRM branch in preparation for an upstream push. Then tragedy struck: Michel’s sharp eyes and testing discovered a potentially fatal bug. While many GPUs provide a frame count register we can use to keep the vblank count accurate (necessary since OpenGL extensions expose an absolute count to applications for some reason), they’re typically only updated at the leading edge of vactive. This means that your application may wakeup at vactive time instead of vblank time, causing ugly tearing; exactly what you’d like to avoid! After a bit of back and forth and a couple of false starts (trying to work around the problem with solutions that turned out to be racy), we decided to go back to using the atomic counter (which is only updated at interrupt time) for wakeups, rather than the hw register, using the latter for keeping the counter accurate across interrupt disable periods.

Which brings us to last week. I hacked up the scheme described above and started testing. As I found and fixed bugs (well actually Michel probably found most of them), I discovered that the API could actually be simplified a bit, and some of the code to compensate for corner cases was no longer necessary, so both the wraparound compensation logic in the pre/post modeset ioctl and the funky accounting we tried to do there could be removed. The result, I hope, is ready for upstream finally.

So where does that leave us, API-wise? Well, on the userland front we have a new ioctl, DRM_IOCTL_MODESET_CTL, with _DRM_PRE_MODESET and _DRM_POST_MODESET arguments. It should be called with _DRM_PRE_MODESET in userland drivers prior to any activity that resets the hw frame counter (typically mode setting). When the mode set completes, it should be called again with _DRM_POST_MODESET. These calls tell the kernel to account for any lost events so that the vblank count exposed to applications can stay accurate.

On the driver front, there are a few different calls and callbacks:

  • drm_vblank_get - increase the refcount on the vblank counter

    This call just tells the core code that the caller is actively using the vblank counter for something, e.g. scheduled buffer swaps or a blocking vblank wait call.

  • drm_vblank_put - decrease the refcount

    Tell the core you’re done with the vblank counter. When the refcount reaches 0, the kernel knows it can disable the interrupt at some point in the future.

  • drm_vblank_init - initialize the core vblank code

    Should be called at driver load time or IRQ init ioctl time to init the core.

  • driver.get_vblank_counter - return the current hw frame count

    Used by the core code to keep the count accurate across interrupt enable/disable periods.

  • driver.enable_vblank - enable vblank interrupts on a given CRTC

    Used by the core to enable interrupts when the refcount increases.

  • driver.disable_vblank - disable vblank interrupts on a given CRTC

    Used by the core to disable interrupts after a timeout period if the refcount is 0.

With a few simple changes, a given DRM driver can support the new scheme to save power. If you find bugs or have issues with the new APIs, let me know and/or file a bug at


Permalink 08:03:30 pm, by jbarnes Email , 373 words, 7445 views   English (US)
Categories: News

Prepping the PCI tree

Figured I’d give an overview of the latest PCI stuff for those of you that don’t drink from the lkml firehose.

The PCI linux-next branch was a bit more exciting than I expected it to be. We’ve got lots of good changes queued up. Some of the highlights:

  • PCI slot detection driver (from Alex Chiang)
    This driver exposes additional per-slot information that can help users identify where slots are physically located, making hotplug easier to deal with.
  • ROM allocation avoidance (Gary Hade)
    With the “don’t allocate space for ROMs” patch reverted, lots of address space can be gobbled up by unnecessary expansion ROMs. To prevent this on large systems, Gary added an option eschew ROM allocation, so that machines not needing access to the ROMs can use more of their address space for important MMIO and I/O regions instead.
  • PCIe hotplug cleanups/fixes (Kenji Kaneshige)
    Kenji spent a lot of time working on improving the PCIe and other hotplug drivers. Things should be more reliable and the code should be easier to follow now thanks to his efforts.
  • suspend/resume & wakeup enhancements (Rafael J. Wysocki)
    Rafael coded up quite a few improvements to our suspend/resume infrastructure, and fixed up PCI/ACPI wakeup while he was at it. The improved wakeup code should work on more platforms and in more situations than the old code, but we still expect additional platform specific quirks and workarounds will be necessary, so testing in this area is welcome. But everyone’s already setting their systems to go to sleep automatically though, for power savings & general “green” goodness, right? These improvements should make things like wake-on-lan a bit more reliable, so if you’re not already in the green camp, please give these bits a try.

There’s also an assortment of fixes here; hopefully we haven’t broken anything too badly…

The bottom line is this though: if you’ve been hesitant to try suspend/resume with Linux, or have had bad wake-on-lan or other wakeup event experiences, or you use PCI hotplug at all, this is a good release for you to try. You can report bugs to, and/or and we’ll take a look!


Permalink 10:44:20 pm, by jbarnes Email , 258 words, 5272 views   English (US)
Categories: News

Fun in Folsom

Just got back from a nice dinner & “gelato” (it was really ice cream) with Keith & Nanhai. We went to the Cliff House here in Folsom; we all ended up getting tasty steaks.

But back to the matter at hand. We’re all here at GfxCon 2008, an Intel event that brings together graphics architects and developers from across the company. There’s a lot of fun stuff going on, with some good sessions today and interesting demos (though of course I can’t talk about any of them, you’ll just have to wait for the products!).

The best part though has been the networking. It’s great to meet the developers I’ve only worked with over email, and have discussions face to face. Keith and I had some good brainstorming sessions about how to handle hardware contexts, and how we want to deal with vblank syncing in the GEM-enabled world. Fortunately, our discussions ended up sounding very similar to the discussions I had with krh back at XDC about vblank syncing in DRI2. Now I just have to code it up…

Hm, and let’s see how I’ve done keeping my promises from last week:

  • SSC detection/usage: still need review before pushing
  • TV detection: still need review before pushing
  • fbc fixes: pushed
  • memory arbitration: test patch attached to 16169
  • page flipping/buffer swap fixes: still working on these
  • PCI “what’s next” msg: still working on it

Hopefully I’ll be able to find time tomorrow with Nanhai or Keith to review and push some of the stuff above… Then on to hardware contexts.


Permalink 08:09:17 pm, by jbarnes Email , 447 words, 14800 views   English (US)
Categories: Background

a bit of history

In order to start things off on the right foot, so to speak (i.e. start out with real content), I figured it might be nice to cover some recent history.

Things have been fairly busy on the Intel graphics front these days; Keith & Eric (or should I say Eric & Keith) have been hard at work getting the new GEM infrastructure in shape. They put together the new framework remarkably quickly; most of the delays recently are due to communication with the hardware guys about various issues, since GEM pushes the limits of our chipsets in a few different ways.

For my own part, it seems like I’ve been spending a lot of time looking at VBIOS tables these days. Over the past few of weeks I’ve added support to the DRM for TV output detection & LFP timings based on the Intel VBTs, and lately I’ve been working to add the same TV output detection plus spread spectrum support to the xf86-video-intel driver. Things are looking good on the SSC front so far: no reports of failure yet and at least one group is using the new patch to avoid audio noise inducing EMI. Hopefully I’ll be able to push it upstream next week. I’ve also got fixes for framebuffer compression and better memory arbitration queued up (well, mostly in my head at this point) that I’ll try to get into the 2.4 release, but since I’ll be out in Folsom at an Intel conference most of next week, that might be tricky.

On the 3D front, I’ve got some fixes for page flipping and buffer swapping on 965 put together; they need more testing (and the DRM vblank code needs more fixing on i915), but I’m hoping to have that together soon. Defaulting to vblank sync’d buffer swaps makes a lot of sense, but only if the underlying vblank code is solid.

PCI in Linux has been pretty busy these days too, more so than I thought it would be. Linus just pulled a few crash fixes for 2.6.26 recently, and the 2.6.27 queue is getting pretty full (TODO: post “what’s in pci linux-next” for everyone). Things are looking good though: VPDs are supported on older cards now, hotplug is getting a lot of attention, and we’ve got some shiny, new early debug code courtesy of Yinghai Lu, our resident coding machine. Oh and I almost forgot all the suspend/resume stuff… Rafael, our highly prolific suspend/resume maintainer, has posted several patchsets that really improve our suspend/resume callback architecture, and fixed up the platform wakeup design while he was at it.

Overall, things are busy as usual, but that’s how it ought to be.

Permalink 07:36:01 pm, by jbarnes Email , 29 words, 36612 views   English (US)
Categories: News

Ok, so I have a blog. The *intent* here is to post frequently about my various Linux & gfx related activities, but note that intent doesn’t always become reality…

Virtuous blogs

 << Current>>
Jan Feb Mar Apr
May Jun Jul Aug
Sep Oct Nov Dec



XML Feeds

What is RSS?

Who's Online?

  • Guest Users: 27

powered by b2evolution free blog software