Virtuous blogs jbarnes' braindump


English (US)   dri2, performance, and tiling  -  Categories: Announcements [A]  -  @ 07:38:49 pm

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

Trackback (0)

Trackback address for this post:

This is a captcha-picture. It is used to prevent mass-access by robots.

Please enter the characters from the image above. (case insensitive)


No Trackbacks for this post yet...


No Pingbacks for this post yet...

powered by b2evolution free blog software

Contact the admin - Credits: blog soft | budget hosting | adsense