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).
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.
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!
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. :)
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.
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 184.108.40.206 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.
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:
- usable EXA support
- support for GEM (if supported by the currently running kernel)
- support for kernel mode setting (again, if the underlying kernel supports it)
- no more video tearing with textured video & XvMC
- Bug fixing
- 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): http://cworth.org/blog/technical/. 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.