# 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/mesa.git;a=shortlog;h=mesa_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/drm.git;a=commit;h=46e9274e8538e5b0517f611dca99dde611f4e95d

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:

```

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.

```

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.

```

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:

```

./autogen.sh

make

make clean && make distclean

rm -rf autom4te.cache

```

If that works you can now package the directory:

```

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.

```

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:

```

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:

```

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:

```

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

```

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

```

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

Greets,

TobiasLast edited by LiquidAcid on Wed Sep 10, 2008 8:33 pm; edited 5 times in total

----------

## 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@lists.sourceforge.net/msg35958.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:

```

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"

```

 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:

```

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:

```

#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  :Smile: 

----------

## Master of the Darkside

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

I did notice something weird:

```

localhost linux-core # lsmod

Module                  Size  Used by

i915                   86792  2

drm                   177632  3 i915

iwl3945                98804  0

```

```

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:

```

[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  :Wink: 

----------

## truekaiser

your first patch.

```

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

 *LiquidAcid wrote:*   

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

----------

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

 *Master of the Darkside wrote:*   

> I did that, still no result.

 

What do you mean by "no result"?

 *Master of the Darkside wrote:*   

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

 

And introduces some ugly tearing, no thanks  :Wink: 

 *Master of the Darkside wrote:*   

> 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  :Wink: 

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

 *Quote:*   

> What do you mean by "no result"? 

 

Same dmesg errors, no acceleration, screen corruption.

 *Quote:*   

> 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

 *LiquidAcid wrote:*   

> 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/Support/Linux.html

refuses to build against the patched kernel with the following error.

```

 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

 *truekaiser wrote:*   

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

 

At least it was not a problem with the patch itself  :Smile: 

 *truekaiser wrote:*   

> though still i ran into problems, the rt2860 driver from here http://www.ralinktech.com/ralink/Home/Support/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.

 *truekaiser wrote:*   

> 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

 *LiquidAcid wrote:*   

> 
> 
> 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  :Wink: 

----------

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

----------

## gman8

libdrm-2.4.0, xorg-server-1.5.0, mesa-7.2, and xf86-video-intel-2.5.0 was released, but ttm still does not work, and gem is still not out yet, so this is what i did:

1. download http://cgit.freedesktop.org/mesa/drm/tree/libdrm/xf86mm.h, put it in /usr/local/include/xf86mm.h

2. run EXTRA_ECONF=--enable-ttm-api emerge mesa, press Ctrl-Z right when configure is done

3. add:

```
#include <xf86mm.h>
```

   to the beginning of these files:

   /var/tmp/portage/media-libs/mesa-7.2/work/Mesa-7.2/src/mesa/drivers/dri/common/dri_util.h

   /var/tmp/portage/media-libs/mesa-7.2/work/Mesa-7.2/src/mesa/drivers/dri/i915/intel_bufmgr_ttm.c

4. continue the build by running fg

5. restart x (if you are on it)

there you have it!

EDIT: changed media-libs/mesa to media-libs/mesa-7.2 (thanks to dmpogo)Last edited by gman8 on Fri Oct 31, 2008 12:23 am; edited 2 times in total

----------

## dmpogo

 *gman8 wrote:*   

> libdrm-2.4.0, xorg-server-1.5.0, mesa-7.2, and xf86-video-intel-2.5.0 was released, but ttm still does not work, and gem is still not out yet, so this is what i did:
> 
> 1. download http://cgit.freedesktop.org/mesa/drm/tree/libdrm/xf86mm.h, put it in /usr/local/include/xf86mm.h
> 
> 2. run EXTRA_ECONF=--enable-ttm-api emerge mesa, press Ctrl-Z right when configure is done
> ...

 

on my machine the path seems to be

/var/tmp/portage/media-libs/mesa-7.2/work/Mesa-7.2/src/mesa/drivers/dri/common/dri_util.h

etc

----------

## dmpogo

 *gman8 wrote:*   

> libdrm-2.4.0, xorg-server-1.5.0, mesa-7.2, and xf86-video-intel-2.5.0 was released, but ttm still does not work, and gem is still not out yet, so this is what i did:
> 
> 1. download http://cgit.freedesktop.org/mesa/drm/tree/libdrm/xf86mm.h, put it in /usr/local/include/xf86mm.h
> 
> 2. run EXTRA_ECONF=--enable-ttm-api emerge mesa, press Ctrl-Z right when configure is done
> ...

 

works fine !   glxgears went from that 50 to 280.  Not spectacular, but improvement  :Smile: 

----------

## bec

Thanks for the guide!

I have a question, what kernel are you using?

----------

## dmpogo

 *bec wrote:*   

> Thanks for the guide!
> 
> I have a question, what kernel are you using?

 

As for me, I was on gentoo-sources-2.6.26-r1

----------

## gman8

ok, I have ttm working, but the performance is only about 80% of that of the original version of mesa (200fps vs 150fps in glxgears.) It doesn't really matter as long as redirected opengl works, but the performance should be better, not worse. What gives? I have an Intel 865G.

----------

## dmpogo

Hei playing with that I noticed that somehow driconf tells me

could not connect any configurable direct-rendering devices

while

Code:

$ xdriinfo

Screen 0: i965

$ xdriinfo options i965

Driver "i965" is not installed or does not support configuration

This is with GM965, xf86-video-intel-2.5.0, mesa-7.2 patched for ttm

glxinfo is normal, glxgears, as I said went up with ttm.

(I have not tried xdriinfo before ttm patch, but I bet it was the same)

----------

## Biszkopt

```

checking for xf86mm.h... no

```

Make i was wrong?

----------

## gman8

 *Biszkopt wrote:*   

> 
> 
> ```
> 
> checking for xf86mm.h... no
> ...

 

download http://cgit.freedesktop.org/mesa/drm/plain/libdrm/xf86mm.h and put it in /usr/local/include. If that doesnt work put it in /usr/include.

----------

## dmpogo

Actually, I found out that it is ttm patch that kills driconf.  Without it driconf works just fine, allows to set VBLANK be set to off, and fps for glxgears go up to 550 range (from 200 with ttm patch in).

So no I'm not sure ttm patch gains anything.

----------

