01/28/09
dri2, performance, and tiling -
Categories: 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 intel-gfx@lists.freedesktop.org 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.
Comments:
using xf86-video-intel 2.6.1, it got an front tiling buffer rejection, and glxgears around 820 fps;
while using xf86-video-intel master, after an filing buffer rejection, it try to allocate again, then glxgears fps only reached around 660 fps...
My system is a Thinkpad X60 with 945GM
Permalink
01/30/09 @ 16:26 If you see something in your kernel log about "can't read MCHBAR", then you'd also need the MCHBAR allocation patch I posted (see the intel-gfx list archives for that).
Permalink
01/30/09 @ 16:55 Yeah the patches have been tested and included in the upstream kernel. Several related fixes have also gone in recently, so if you have a 9xx and have had poor performance, it's worth trying out the latest bits again. Please report problems or questions to the intel-gfx@lists.freedesktop.org mailing list.
Permalink
02/17/09 @ 14:35 I'm asking because tiling works fine for me on single channel and doesn't work at all (with huge performance regression) on dual channel.
I'm using gma950 on lenovo 3000 n100 laptop.
Permalink
03/05/09 @ 09:39 Permalink
03/06/09 @ 20:51 Permalink
03/22/09 @ 08:57 Permalink
03/22/09 @ 22:44 · http://www.wasmachinekeuze.nl/ Permalink
05/24/09 @ 13:36 Leave a comment:
Trackback address for this post:
Trackbacks:
No Trackbacks for this post yet...
Pingbacks:
No Pingbacks for this post yet...
RSS Feed