Intel i915: Using TTM with mesa-7.1/xorg-server-1.5

[LiquidAcid]

Hi there,

this is a guide for everyone using an Intel i915 graphics chipset on their system and just having updated their X stack to xorg-server-1.5 plus mesa-7.1.

The problem:
mesa's i915 driver is dead slow when not backed up by a memory manager like TTM or GEM (the one that replaced TTM). mesa-7.1 only supports the TTM API, since the GEM code was not merged before the release.
In more detail: The mesa-7.1 release was done from the 7.2-branch of the mesa/mesa repository hosted on FDO. Take a look at it:
http://gitweb.freedesktop.org/?p=mesa/m ... 7_2_branch

The GEM part was already merged, but for the 7.2-branch it was reverted, leaving mesa-7.1 only with TTM support. Furthermore this is deactivated inside the standard ebuild that is currently found in portage.

Without TTM the Intel i915 is especially slow when it comes to OpenGL's glDrawPixels and glReadPixels calls, these are for example use by wine for some emulation features for old DX versions. Moreover these calls are pretty performance critical.
Also some extensions like PBO (pixel buffer objects) and FBO (frame buffer objects) are not exported by the driver when no memory manager is found. Again wine suffers when these extensions are lacking. Trying to play any kind of (old) windows games through wine on a Intel i915 is not an option because it results in a slide show.
So it's time to change this and get some performance out of the chip.

The setup:
My current setup looks like this:

• xorg-server-1.5.0
• mesa-7.1
• xf86-video-i810-2.4.2-r1
• libdrm-2.3.1
• gentoo-sources-2.6.26-r1

We want to start with this kind of setup. I can already tell you that we have to modify the ebuild for mesa-7.1 and install a different version of libdrm, plus the correct kernel module of course.

Searching for TTM:
The big problem is that the latest git master snapshot of mesa/drm already has TTM ripped out and replaced by GEM. We can't use GEM with the mesa version we have installed. In my case I didn't want to update mesa to git as well. The worst thing I wanted to do at this point was patching the mesa ebuild, nothing more. No upgrading all the X stack to git, THIS was not an option for me.

So I had to find a snapshot of mesa/drm with TTM still intact. Looking at the commit history indicated that this snap should do it:
http://gitweb.freedesktop.org/?p=mesa/d ... e611f4e95d

The commit after this one merges the GEM branch and a commit or two later the TTM API is ripped out. So we want this specific version:

Code: Select all

git clone git://anongit.freedesktop.org/git/mesa/drm drm-ttm
cd drm-ttm
git checkout -b ttm 46e9274e8538e5b0517f611dca99dde611f4e95d

We should have a copy of the mesa/drm sourcecode now that still has all TTM bits intact. We can use this now to build a new libdrm package+ebuild and the corresponding kernel module.

Patching the kernel:
We also need to patch the gentoo-sources-2.6.26-r1 tree, otherwise we'll get three unknown symbol errors when compiling.
You need two patches I uploaded here:
http://www.math.uni-bielefeld.de/~tjakobi/drm-ttm/

One additional thing you have to patch manually (I didn't find a patch and didn't bother to create one myself) is the file:
arch/x86/kernel/init_task.c
There you replace "EXPORT_UNUSED_SYMBOL(init_mm);" with "EXPORT_SYMBOL(init_mm);"

This should do it, don't forget to recompile your kernel though (and reboot before modprobbing the module later on).

Packaging libdrm:
I was going to name my ebuild libdrm-2.4.0-r1 and put it into my local overlay.

Code: Select all

cp -R drm-ttm libdrm-2.4.0
cd libdrm-2.4.0
rm -rf bsd-core ; rm -rf linux-core

bsd-core and linux-core are not needed for the libdrm build, we also want to change the version reported by libdrm.

Code: Select all

libdrm/Makefile.am:
libdrm_la_LDFLAGS = -version-number 2:3:0 -no-undefined

We change the "2:3:0" string to "2:4:0". Now a quick test followed by usual cleanup:

Code: Select all

./autogen.sh
make
make clean && make distclean
rm -rf autom4te.cache

If that works you can now package the directory:

Code: Select all

cd ..
tar cvjf libdrm-2.4.0.tar.bz2 libdrm-2.4.0/

Put the libdrm-2.4.0.tar.bz2 into your distfiles directory (usually /usr/portage/distfiles) and possibly backup somewhere else, in case you clean your distfiles.

Now copy the libdrm-2.3.1.ebuild over to your overlay (x11-libs/libdrm), renaming it to libdrm-2.4.0-r1.ebuild (don't forgot to add keywords to your package.keywords file). You have to change the "SRC_URI" line in the ebuild as well. Just change the extension of the archive from gz to bz2.

Code: Select all

ebuild libdrm-2.4.0-r1.ebuild digest

This should digest your new libdrm ebuild. Try installing it now (emerge -uva libdrm).

Please note: This can also possibly be done by grabbing a GIT (9999) ebuild and forcing it to checkout a specific version (the commit ID I mentioned above). I didn't try that myself and did it the more "manual" way.

Patching mesa ebuild
The current mesa ebuild in portage always has TTM disabled, we want to change that. Copy the mesa-7.1.ebuild over to your overlay (media-libs/mesa), renaming to to something like mesa-7.1-r1.ebuild (think about your package.keywords). Now look for this line:

Code: Select all

myconf="${myconf} --disable-ttm-api"

And replace disable with enable. Also change the comment to reflect the change. Copy over the lib directory from the files dir to your overlay (contains LA files) and digest the new ebuild. Now update mesa.

The DRM kernel module:
I did not create a x11-drm ebuild for that one. One reason is that the important part of the ebuild is the kernel module itself. I'm not sure if it is that important to have this managed by portage.

So I'm just building this directly from my drm-ttm directory. However there is one include missing in linux-core, so we add it here:

Code: Select all

cd drm-ttm/linux-core
wget "http://www.math.uni-bielefeld.de/~tjakobi/drm-ttm/i915_gem.h"

The include goes into i915_gem_tiling.c, you can just add it to the other include at the top of the file. After adding the new header the include area should look like this:

Code: Select all

#include "drmP.h"
#include "drm.h"
#include "i915_drm.h"
#include "i915_drv.h"
#include "i915_gem.h"

This should be enough patching to get the kernel module to build. Now proceed with compiling...

Code: Select all

cd drm-ttm
./autogen.sh
CFLAGS="..." LDFLAGS="..." ./configure
cd linux-core
make DRM_MODULES="i915"

Check /etc/make.conf for your CFLAGS and LDFLAGS. This should create both the drm.ko and i915.ko, make install to copy them over to your kernel lib directory (into the extra dir).

Code: Select all

depmod -a
modprobe i915

If that works you seem to have done everything correctly.

Testing TTM:
Restart your X and check with glxinfo for GL_ARB_pixel_buffer_object and GL_EXT_framebuffer_object. If it's there your mesa i915 driver should now be powered by TTM.

At least it's now for me.

Appendix:
I should note that this is only temporary solution to the 3D acceleration problem on Intel i915 hardware.

We already have a 2.6.27-rc kernel branch patched with the latest DRM-GEM code (Eric Anholt's linux-2.6 tree on FDO) and can expect that GEM gets merged upstream in the 2.6.28 kernel.

Meanwhile a new xf86-video-i810/intel driver should be out, with the GEM branch merged and fully utilizing the power of the new memory manager. As soon as the 2.6.28 kernel (with GEM) and the corresponding intel (2D) driver is out, I'm going to upgrade again - this time also to mesa git master.

Please note that TTM was never actually "released" and it's not supported in any way. So if your system crashes, lockups, whatever you won't get any kind of support. Not from me, not from the mesa, X or kernel guys. That's different with GEM because Intel is currently pushing it by a great deal.

So only use this (hackish) approach as long as you have to.

Greets,
Tobias

[bec]

Hello Tobias,

Following your guide I found a problem compiling mesa:

checking for xf86mm.h... no
configure: error: xf86mm.h required for TTM.

Maybe is because of the following bug?

http://www.mail-archive.com/dri-devel@l ... 35958.html

[LiquidAcid]

Hmm, yes - that looks like it.
So you have to install libdrm before patching and installing mesa. This should work, since for me:

Code: Select all

equery belongs xf86mm.h
[ Searching for file(s) xf86mm.h in *... ]
x11-libs/libdrm-2.4.0-r1 (/usr/include/xf86mm.h)

So after the libdrm update mesa should build with TTM. I'm going to reorder my guide, thanks for pointing that out!

[bec]

There is another problem, to create the kernel module I cd into drm-ttm but there is not configure file created.

I guess ./autogen.sh (should?) be called to create configure ...

[LiquidAcid]

Oh yes, that's needed of course. I think I only put that in the first time (when packaging libdrm), but forgot it for the kernel module.

Now corrected, thanks again!

[truekaiser]

so let be frank here.. is this going to be the only way now to have full 3d on intel cards till this mess is worked out?

[LiquidAcid]

Upgrade your X stack to GIT, mesa to git master and the kernel to anholt's drm-gem branch and you can enjoy acceleration through GEM.

Probably also works without updating the whole X stack to GIT, but I'm not sure about that. And I didn't want to experiment that long with the whole setup.
For me updating the kernel to a post 2.6.27-rc version was not an option. So I was stuck with TTM, since you have a REALLY hard time to get GEM working with the 2.6.26 series. At least I had such big problems that I returned to TTM.

[Master of the Darkside]

Thanks for the great howto, but for me building the drm module fails:

make DRI_MODULES="i915"

Code: Select all

 CC [M]  /usr/local/src/drm-ttm/linux-core/i915_gem.o
  CC [M]  /usr/local/src/drm-ttm/linux-core/i915_gem_debug.o
  CC [M]  /usr/local/src/drm-ttm/linux-core/i915_gem_proc.o
  CC [M]  /usr/local/src/drm-ttm/linux-core/i915_gem_tiling.o
/usr/local/src/drm-ttm/linux-core/i915_gem_tiling.c: In function 'i915_gem_detect_bit_6_swizzle':
/usr/local/src/drm-ttm/linux-core/i915_gem_tiling.c:118: error: implicit declaration of function 'pci_read_base'
make[2]: *** [/usr/local/src/drm-ttm/linux-core/i915_gem_tiling.o] Error 1
make[1]: *** [_module_/usr/local/src/drm-ttm/linux-core] Error 2
make[1]: Leaving directory `/usr/src/linux-2.6.26-gentoo-r1'
make: *** [modules] Error 2

EDIT:

I did apply that patch with:

Code: Select all

patch -p0 < 0002-pci_read_base.patch

Any clues?

[LiquidAcid]

Yeah, that's another thing I forgot to add to the guide. That happens if you first figure out how it all works and builds correctly and afterwards start to write down what you have done.

Fetch the i915_gem.h file from http://www.math.uni-bielefeld.de/~tjakobi/drm-ttm/ and put it into the linux-core directory.

Then open i915_gem_tiling.c in a text editor and add i915_gem.h to the defines, should afterwards look like that:

Code: Select all

#include "drmP.h"
#include "drm.h"
#include "i915_drm.h"
#include "i915_drv.h"
#include "i915_gem.h"

Think this should do it. Sry for that, I'm already changing the guide

[Master of the Darkside]

Thanks, it worked, I guess... but I can see no improvement


I did notice something weird:

Code: Select all

localhost linux-core # lsmod
Module                  Size  Used by
i915                   86792  2
drm                   177632  3 i915
iwl3945                98804  0

Code: Select all

localhost linux-core # du -b `find /lib/modules/*|grep "drm.ko\|915.ko"`
125300  /lib/modules/2.6.26-gentoo-r1/extra/i915.ko
267986  /lib/modules/2.6.26-gentoo-r1/extra/drm.ko
125300  /lib/modules/2.6.26-gentoo-r1/kernel/drivers/char/drm/i915.ko
267986  /lib/modules/2.6.26-gentoo-r1/kernel/drivers/char/drm/drm.ko

Seems like the sizes don't match. But I may be wrong about this.

Dmesg shows an error:

Code: Select all

[drm] Initialized drm 1.1.0 20060810
PCI: Unable to reserve mem region #3:10000000@d0000000 for device 0000:00:02.0
ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:02.0 to 64
[drm:i915_gem_detect_bit_6_swizzle] *ERROR* pci_read_base failed: -2
[drm] Initialized i915 1.13.0 20080730 on minor 0
[drm] Used old pci detect: framebuffer loaded

[LiquidAcid]

You should of course delete your old modules

[truekaiser]

your first patch.

Code: Select all

From 2a4a7ec5674fae779b367b740f829780b6425667 Mon Sep 17 00:00:00 2001
From: Keith Packard <keithp@keithp.com>
Date: Tue, 27 May 2008 14:12:07 -0700
Subject: [PATCH] Export shmem_file_setup for DRM-GEM
 (cherry picked from commit c9506226575e897745f75010fb81ac68533dc1e6)

---
 mm/shmem.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/mm/shmem.c b/mm/shmem.c
index f514dd3..2c4b6b3 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -2616,6 +2616,7 @@ put_memory:
        shmem_unacct_size(flags, size);
        return ERR_PTR(error);
 }
+EXPORT_SYMBOL(shmem_file_setup);

 /**
  * shmem_zero_setup - setup a shared anonymous mapping
--
1.5.5.4

just sits there and hangs..

[LiquidAcid]

How do you apply it? A hanging patch sounds quite weird to me. Must be the patch executable hanging.

Otherwise I dunno what should be wrong with the patch. Standard patch format you get with git-format-patch... nothing special here.

[Master of the Darkside]

You should of course delete your old modules

First thing I did: overwrite the old modules with the new ones from the extra dir.
Anyway, downgrading now. With errors.

[LiquidAcid]

Just delete the old modules and leave the new ones in the extra dir.

1) Shutdown X
2) Unload i915.ko and drm.ko
3) Remove old modules
4) make install OR make sure that the new modules are inside the extra dir
5) depmod -a
6) modprobe i915 and look for critical errors in dmesg
7) start X server again

Because of some reinitialization issues with the intel driver it would be also good to include a full restart of the system.

[Master of the Darkside]

I did that, still no result. Thanks anyway... for now I reverted to mesa 7.1 and libdrm-3.1.
I've installed x11-misc/driconf and disabled vsync for dri, which gives me good opengl performance. 2d is a bit slow, but I can manage. Hope new versions of intel driver, mesa, xorg, libdrm will come out soon.

[LiquidAcid]

I did that, still no result.

What do you mean by "no result"?

I've installed x11-misc/driconf and disabled vsync for dri, which gives me good opengl performance.

And introduces some ugly tearing, no thanks

Hope new versions of intel driver, mesa, xorg, libdrm will come out soon.

libdrm-2.3.1 came out 2 months ago, libdrm-2.3.0 cam out 22 months ago... I don't think we'll get anything new in the next time
Same goes for mesa: mesa-7.0 14 months ago!

This laptop is already some years old. Waiting another 2 years before I can finally get some decent 3D acceleration is really no options. By the time I have a new laptop.

[Master of the Darkside]

What do you mean by "no result"?

Same dmesg errors, no acceleration, screen corruption.

And introduces some ugly tearing, no thanks

Works for me with no visible side-effects.

[LiquidAcid]

You mean the i915_gem_detect_bit_6_swizzle errors? You can ignore them for now, since they origin from the GEM code which isn't used at all when working with the TTM API.

The screen corruptions are of course another thing, I didn't encounter anything like that.

[truekaiser]

How do you apply it? A hanging patch sounds quite weird to me. Must be the patch executable hanging.

Otherwise I dunno what should be wrong with the patch. Standard patch format you get with git-format-patch... nothing special here.

i fixed it myself. it seems the online documentation on 'patch' had the syntax wrong. though still i ran into problems, the rt2860 driver from here http://www.ralinktech.com/ralink/Home/S ... Linux.html
refuses to build against the patched kernel with the following error.

Code: Select all

 CC [M]  /home/kevin/2008_0708_RT2860_Linux_STA_v1.7.0.0/os/linux/../../os/linux/rt_main_dev.o
/home/kevin/2008_0708_RT2860_Linux_STA_v1.7.0.0/os/linux/../../os/linux/rt_main_dev.c: In function 'rt_ieee80211_if_setup':
/home/kevin/2008_0708_RT2860_Linux_STA_v1.7.0.0/os/linux/../../os/linux/rt_main_dev.c:804: error: 'struct net_device'has no member named 'nd_net'
make[2]: *** [/home/kevin/2008_0708_RT2860_Linux_STA_v1.7.0.0/os/linux/../../os/linux/rt_main_dev.o] Error 1
make[1]: *** [_module_/home/kevin/2008_0708_RT2860_Linux_STA_v1.7.0.0/os/linux] Error 2
make[1]: Leaving directory `/usr/src/linux-2.6.26-gentoo-r1'
make: *** [LINUX] Error 2

not to mention the required xorg-server for this how too doesn't work.

[LiquidAcid]

it seems the online documentation on 'patch' had the syntax wrong.

At least it was not a problem with the patch itself

though still i ran into problems, the rt2860 driver from here http://www.ralinktech.com/ralink/Home/S ... Linux.html
refuses to build against the patched kernel with the following error.

And it even won't build against an unpatched 2.6.26-r1 kernel, since the patches don't touch the network code.

not to mention the required xorg-server for this how too doesn't work.

Huh? The xorg-server-1.5 release builds perfectly fine here. You should really report build errors on the FDO bugtracker!

[truekaiser]

Huh? The xorg-server-1.5 release builds perfectly fine here. You should really report build errors on the FDO bugtracker!

i can try again this weekend. right now i don't have the time.

[thelinuxfr]

Hi,

View here: http://code.google.com/p/thelinux/source/detail?r=24 and http://code.google.com/p/thelinux/

Fix bug

[ChojinDSL]

Could you post some kind of framerate comparison of before and after?
Not just glxgears, but maybe some common games that use opengl, native and through wine.

[g0rg0n]

ah.. so this was the reason for extreme low fps

(i'm getting around 50 with glxgears =S) after upgrade