We recently started supporting DRI2 in xf86-video-intel and the Mesa drivers, but since then people have started to report performance problems, especially on pre-965 chips (and even crashes on older chips).
I recently looked into those problems, with a couple of theories in mind. Some of the problems reported were so bad, I thought for sure there must be another vblank related bug hiding somewhere, causing apps to timeout and hang for a few seconds. Another theory was that our lack of tiled rendering on pre-965 was at least partly responsible. Turns out that a real win, especially on low end platforms (going from ~5fps to ~30fps on some platforms & apps).
On pre-965 chips though, in order to render to tiled surfaces, so-called fence registers must be set up surface’s properties (stride, size, tiling mode and address). Until recently we didn’t have a way of making fence registers available in the kernel, but with that code (added to support GTT based mapping in userspace), it was a small effort to get tiled rendering going on pre-965. However, only X tiling is supported at the moment. Mesa uses standard blits to copy data around in some cases, and on pre-965 only X tiled objects can be blitted with the 2D engine. Once we change that we can see how much of a win Y tiling will be on pre-965 (almost surely not as much as going from no tiling to X tiling, but it could be worth a few fps).
But that’s not all. With GEM, tiling parameters need to be known so that software based tiled access can work. Unfortunately on some machines the necessary configuration information (which is stored in the MCH memory config registers) isn’t available, since the BIOS may disable the registers or not allocate I/O space for them. My Eee is one such machine, so I was able to code and test a patch to make the MCH data available where it wasn’t otherwise (additional testing appreciated, see the email@example.com archives for the patch).
On the KMS front, things are coming together. X comes up *much* faster with KMS enabled, and VT switch is nearly instantaneous. All this is great, but there are still some bugs related to framebuffer resize and rotate, and suspend/resume is a little off when mode setting is enabled. Hopefully we can fix most of these before 2.6.29 proper comes out.
I’ve been really bad at dealing with spam on this blog, but I just went through the posts from the last few months and cleaned things up. So if you’ve made comments, you might actually see them now and maybe even see replies…
It’s been an exciting few weeks since my last post (well ok 6 weeks):
- DRM KMS merged (woo-hoo!)
- Wayland running on top of DRM KMS - had fun with Kristian on this one while we were both visiting Hillsboro for Intel meetings
- lots and lots of bug activity
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.