Created attachment 11989 [details]
Xorg.0.log

The driver is compiled from git as of commit eb0754e41824cc23d2dbf8dc70bef7e6e65894ea

(In reply to comment #0)
> Scrolling in firefox and others is extremely slow using EXA + compiz and the
> intel driver for my i945GM. It also causes a very high CPU load on my dual
> core machine.

You need to use current git master of mesa (and possibly fix the zero-copy texture-from-pixmap support in its newly-unified i915 driver).

> Adding MigrationHeuristics to the xorg.conf (see below) helps only a
> very little bit.

"always" is the default anyway, at least upstream...

>   Option       "BackingStore" "on"

This is a bad idea up to and including xserver 1.4.

>   Option       "PageFlip" "on"
>   Option       "TripleBuffer" "on"

These won't give any benefit without changing the 3D driver as above.

Thanks a lot for your help, Michael!

> (and possibly fix the zero-copy
> texture-from-pixmap support in its newly-unified i915 driver).

Stupid question: Do you have any idea how this fix has to look?

(In reply to comment #3)
> 
> > (and possibly fix the zero-copy texture-from-pixmap support in its
> > newly-unified i915 driver).
> 
> Stupid question: Do you have any idea how this fix has to look?

So you've tried it and found it to be broken? It seemed broken here on a quick test, but I haven't had time to look into it.

I tried, and it does not help.
glxinfo gives (extract)
OpenGL vendor string: Tungsten Graphics, Inc
OpenGL renderer string: Mesa DRI Intel(R) 945GM 20061102 x86/MMX/SSE2
OpenGL version string: 1.3 Mesa 7.1

(In reply to comment #5)
> I tried, and it does not help.
> glxinfo gives (extract)

Is the X server using the same version of i915_dri.so? Can you attach gdb to it and verify that intelSetTexOffset is getting called?

You were right, Michael. The X server used the old dri module although my distro's documentation explicitely denies that. ;)
After replacing the old module I cannot start compiz anymore since it complains:

Fatal: No GLXFBConfig for default depth, this isn't going to work

glxgears is extremely slow but reports with LIBGL_DEBUG=verbose

libGL: XF86DRIGetClientDriverName: 1.9.0 i915 (screen 0)
libGL: OpenDriver: trying /usr/lib/dri/updates/i915_dri.so
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 4, (OK)
drmOpenByBusid: Searching for BusID pci:0000:00:02.0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 4, (OK)
drmOpenByBusid: drmOpenMinor returns 4
drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0

I cannot debug my X.Org server since attaching gdb to it simply causes 100% CPU load but does not get me back to the gdb prompt. I do not know what goes wrong loading the symbols...

(In reply to comment #7)
> Fatal: No GLXFBConfig for default depth, this isn't going to work

Ah yes, that's bug 9264. Then again, you should only hit that if you're also using the i915 kernel module from drm git...

Apart from that, zero-copy tfp should be attempted now, so probably no need to attach gdb.

I use drm kernel module i915 from git.
How can I attempt zero-copy-texture from pixmap?

I noticed some strange behaviour:
I put my new i915_dri.so in /usr/lib/dri/updates and a symbolic link to /usr/lib/dri/.
In this configuration glxgears gives me around 600 fps.
Putting the old i915_dri.so to /usr/lib/dri instead of the link I get about 5000(!) fps although it tells me just as before

libGL: XF86DRIGetClientDriverName: 1.9.0 i915 (screen 0)
libGL: OpenDriver: trying /usr/lib/dri/updates/i915_dri.so

(In reply to comment #9)
> How can I attempt zero-copy-texture from pixmap?

By using the i915 kernel module from your kernel instead of from drm git or by using the patch from bug 9264.

WOW, you're great, Michel! Indeed using the old drm makes scrolling very responsive now. Still rendering is not as fast as using XAA, but quite impressive. :)
I also tried with the patch mentioned and the new drm which did not work in the desired way.