Created attachment 18919 [details]
The xorg.conf I used to make the above test

cworth, is this behavior within your expectation for the current code?
Note Novell is considering this kind of issue blocking them switching from XAA to EXA.

I guess it is caused by this commit:
http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-intel.git;a=commitdiff;h=5c9a62a29f62a9ecce37fae98cb01f8217eaba15

(In reply to comment #2)
> cworth, is this behavior within your expectation for the current code?
> Note Novell is considering this kind of issue blocking them switching from XAA
> to EXA.

I don't think it's expected, no.

I'll try to replicate on a 945GM that I have here conviently.

If I don't succeed there, then I will try digging up an 865 to see what that does.

Thanks for your patience on this one,

-Carl

Here are the configurations I tested, trying to reproduce this bug:

Hardware
--------
Acer Aspire One (Intel Atom CPU, Intel 945GM GPU)

Baseline software
-----------------
Linux 2.6.27-rc4 (+GEM)
xserver 1.4.2
xf86-video-intel 2.3.2
KDE (Debian says 5:48---don't know what that means exactly)
Compositing enabled in KDE:
    (Control Center->Desktop->Window Behavior->Translucency for moving windows)

Updated software
----------------
xserver master 		(eb8be3e90a9c9)
xf86-video-intel master	(1cc15ba454fdf)

With the baseline software, I couldn't detect any performance problem with scrolling in firefox, konqueror, or any other applications. I did see problems with moving translucent windows, (the window lagged far behind the mouse cursor), and I measured very slow text rendering, (30,400 glyphs/second for "x11perf -aa10text").

For the updated software, the translucent window movement became very snappy and responsive, and the text rendering improved to 210,000 glyphs/second.

So some things have gotten better, but it's not at all obvious that I've seen the original bug at all. I've yet to see "slow scrolling", (though that's subjective enough that it's possible I might miss it). And obviously, I didn't test with the original hardware, (I had 945GM, not 865), nor even the original software, (I used xserver 1.4.2 not xserver 1.5, and xf86-video-intel 2.3.2 not 2.4.97).

Perhaps both of us can attempt to replicate each other's setup a little more closely to see if we can get more consistent results, (or verify that the bug is fixed in the latest driver).

-Carl

Unfortunately it's hard for me to switch to another distribution for testing, since I have the mentioned hardware only on my office computer, where I need it for my daily work. I would appreciate some more feedback for that from more users. Furthermore it wouldn't be a real-life test if I compiled something by myself, I find it better for other users to use the precompiled packages I get with the distribution from the different repositories, and default settings that these distributions use, for instance for .

Carl: Would you mind attaching the configuration xorg.conf that you used for this test, please, and possibly somehow mark the lines which are important for me? Isn't there some nasty option with a bad value or a hidden default which I might have overlooked? Did you have a look at the configuration I appended? Is it ok?
Is there any reproducible benchmark which gives an output that we could compare, some kind of reference test for this scrolling issue?

I could imagine there is some relation to the chipset and the hardware "around" it, may be some kernel parameter.

I agree, that describing the visual speed of scrolling is a subjective value, but it is not only slow but it really judders in Konqueror 4.1 while it goes fluently after switching back to XAA. This is not to overlook, there is a big difference. This difference was from the beginning when Novell started to use EXA as the default acceleration from Jul 14, the changelog of the package xorg-x11-driver-video shows:
---
* Mon Jul 14 2008 sndirsch@suse.de
- no longer use XAA as default for intel driver; Intel upstream
  developers no longer support it

* Thu Jul 03 2008 sndirsch@suse.de
...
- xf86-video-intel-2.3.2.diff
  * fixed build against libdrm 2.3.1
...
The problem was obvious from this time on because of the new default EXA.

Here is some additional information about the system, where the problem occurs:

Board: MSI 865G Neo-2P
Processor (CPU): Intel(R) Pentium(R) 4 CPU 2.80GHz
Total memory (RAM):  2.0 GB
OS:  Linux 2.6.25.16-0.1-default i686
System:  openSUSE 11.0 (i586)
KDE:  4.1.2 (KDE 4.1.1 (KDE 4.1 >= 20080828)) "release 52.2"

Graphics Hardware Info:
	Vendor:  Intel Corporation
	Model:  865 G
	Driver:  intel

Loaded drivers (lsmod): drm, i915

Xorg as described above.

(In reply to comment #5)
> [..]
> ... and I measured very slow text rendering, (30,400 glyphs/second for
> "x11perf -aa10text").
> 
> For the updated software, the translucent window movement became very snappy
> and responsive, and the text rendering improved to 210,000 glyphs/second.
> [..]

Here is my result for that test (both about a minute after KDE logon and started-up system):

Using EXA:
----------
The X.Org Foundation server version 10501000 on :0.0
from rkrell
Tue Sep 30 14:18:43 2008

Sync time adjustment is 0.1369 msecs.

 400000 reps @   0.0148 msec ( 67600.0/sec): Char in 80-char aa line (Charter 10)
 400000 reps @   0.0150 msec ( 66800.0/sec): Char in 80-char aa line (Charter 10)
 400000 reps @   0.0147 msec ( 68200.0/sec): Char in 80-char aa line (Charter 10)
 400000 reps @   0.0148 msec ( 67800.0/sec): Char in 80-char aa line (Charter 10)
 400000 reps @   0.0147 msec ( 67900.0/sec): Char in 80-char aa line (Charter 10)
2000000 trep @   0.0148 msec ( 67600.0/sec): Char in 80-char aa line (Charter 10)

Using XAA:
----------
x11perf - X11 performance program, version 1.2
The X.Org Foundation server version 10501000 on :0.0
from rkrell
Tue Sep 30 14:12:29 2008

Sync time adjustment is 0.1493 msecs.

 400000 reps @   0.0137 msec ( 72900.0/sec): Char in 80-char aa line (Charter 10)
 400000 reps @   0.0138 msec ( 72400.0/sec): Char in 80-char aa line (Charter 10)
 400000 reps @   0.0135 msec ( 74200.0/sec): Char in 80-char aa line (Charter 10)
 400000 reps @   0.0133 msec ( 75400.0/sec): Char in 80-char aa line (Charter 10)
 400000 reps @   0.0136 msec ( 73300.0/sec): Char in 80-char aa line (Charter 10)
2000000 trep @   0.0136 msec ( 73600.0/sec): Char in 80-char aa line (Charter 10)

(In reply to comment #6)
> Unfortunately it's hard for me to switch to another distribution for testing,
> since I have the mentioned hardware only on my office computer, where I need it
> for my daily work.

Certainly, I understand that.

> Carl: Would you mind attaching the configuration xorg.conf that you used for
> this test, please, and possibly somehow mark the lines which are important for
> me?

Yes, I'll follow up with an attachment. But it's really almost a default configuration, (as it should be). If there are "magic" options needed to get good performance then that's a bug in the X server or driver somewhere.

> Isn't there some nasty option with a bad value or a hidden default which I
> might have overlooked? Did you have a look at the configuration I appended? Is
> it ok?

It looks fine, really. I'd actually recommend not messing with the MigrationHeuristic option, (changing it generally only makes things worse). But I think 'always' is the upstream default now anyway.
 
> Is there any reproducible benchmark which gives an output that we could
> compare, some kind of reference test for this scrolling issue?

That's precisely what I would like to identify! (And when I do, I'll make sure our QA team runs it as part of their standard practice.) But I have no idea what the scrolling issue actually is. Basically, we'll need to get one hardware configuration with two different software cofigurations, (one showing the bug and one not), and then find a test that shows a change, (with x11perf, render_bench, or expedite), or else write one from scratch.

I'd be quite happy to identify or write that test---we just need to find an easy way to turn the bug on or off first. :-)

> I agree, that describing the visual speed of scrolling is a subjective value,
> but it is not only slow but it really judders in Konqueror 4.1 while it goes
> fluently after switching back to XAA.

I'm really glad to have an open dialog with you now for exploring this. Can you describe more precisely what your "scrolling" test is? For example, what URL do you load? Then, how do you scroll? Holding down the down arrow key? Clicking and holding the mouse button in the slider trough? Clicking and holding the mouse button on a slider arrow? Clicking and dragging on the slider itself? Dragging it slowly or wildly up and down?

Another detail that Jesse Barnes asked me to identify is whether the slowness appears immediately after the X server starts, or if it's only after a session has been running for a while, (for example, once video memory is getting filled with lots of pixmaps).

And I'll still attempt to reproduce the bug with something closer to your setup. Matching your software releases would be easy enough for me. Getting my hands on an 865 would be harder, but certainly possible.

If there's any way you could attempt upgrading the X server and driver to see if the problem goes away, then that would be extremely useful. (And of course I'd be happy to help walk you through that process.)

Thanks again,

-Carl

Created attachment 19306 [details]
Carl's minimal xorg.conf file

Here's what I used, (note commented out options for testing various configurations). And also note that there aren't any magic "go fast" options here or anything, (which is how it should be).

-Carl

(In reply to comment #9)
> [..]
> Can you describe more precisely what your "scrolling" test is?
> For example, what URL do you load?

The website has no effect on the scrolling performance that I can see, regardless of the contents and which formatting elements are used.
For quickly testing it, I call for instance http://www.heise.de/ in Konqueror 4.1.1. Rendering on scrolling is slowly, the scrollbar and the site contents judder. It looks like the site contents are divided into several horizontal squares which are copied and filled up slightly on scrolling. During this, the slider and site contents jump in ticks of around a half second instead of moving fluently.

> Then, how do you scroll? Holding down the down arrow key? Clicking
> and holding the mouse button in the slider trough? Clicking and holding the
> mouse button on a slider arrow? Clicking and dragging on the slider itself?
> Dragging it slowly or wildly up and down?

Mostly I test scrolling using the mouse wheel, but also clicking and dragging the slider slowly, not wildly.

> Another detail that Jesse Barnes asked me to identify is whether the slowness
> appears immediately after the X server starts, or if it's only after a session
> has been running for a while, (for example, once video memory is getting filled
> with lots of pixmaps).

It happens immediately after startup and stays at the same level of non-performance.

> And I'll still attempt to reproduce the bug with something closer to your
> setup. Matching your software releases would be easy enough for me. Getting my
> hands on an 865 would be harder, but certainly possible.
> 
> If there's any way you could attempt upgrading the X server and driver to see
> if the problem goes away, then that would be extremely useful. (And of course
> I'd be happy to help walk you through that process.)

I use precompiled packages from the OpenSUSE repository at
http://download.opensuse.org/repositories/X11:/XOrg/openSUSE_11.0/
which are almost daily updated even with the latest GITs of drivers.
Each time I see a change that could concern the problem discussed here I switch to EXA and repeat the test. The xorg.conf I configure manually, not letting it manipulate by SaX2 or another tool, for being sure in this situation.
If I should try something else tell me what and where to get, please, including benchmarks (which should not necessarily destroy my system ;-) ).

Thanks, René

Just for information, here is my configuration:

Slack 12.1, KDE 3.5.9, P4 3GHz, 2Gb RAM, intel 82865G

g4b0@slack:~$ su
Password:
root@slack:/home/g4b0# lspci -v

[..snip..]
00:02.0 VGA compatible controller: Intel Corporation 82865G Integrated Graphics Controller (rev 02) (prog-if 00 [VGA controller])
        Subsystem: ASUSTeK Computer Inc. Unknown device 2572
        Flags: bus master, fast devsel, latency 0, IRQ 18
        Memory at f0000000 (32-bit, prefetchable) [size=128M]
        Memory at fe780000 (32-bit, non-prefetchable) [size=512K]
        I/O ports at eff0 [size=8]
        Capabilities: [d0] Power Management version 1
        Kernel modules: intelfb
                        ^^^^^^^
[..snip..] 

First question: How do I tell my slack to use xf86-video-intel instead intelfb?
Moreover, I need to manually load intelfb module, and it was in modprobe.d/blacklist..

root@slack:/home/g4b0# lsmod | grep intel
intelfb                37924  0
i2c_algo_bit            9476  1 intelfb
snd_intel8x0           31900  0
snd_ac97_codec         98724  1 snd_intel8x0
snd_pcm                72068  3 snd_pcm_oss,snd_intel8x0,snd_ac97_codec
snd                    47716  9 snd_seq_oss,snd_seq,snd_seq_device,snd_pcm_oss,snd_mixer_oss,snd_intel8x0,snd_ac97_codec,snd_pcm,snd_timer
i2c_core               22528  3 intelfb,i2c_algo_bit,i2c_i801
intel_agp              25236  1
agpgart                30664  4 intelfb,drm,intel_agp
snd_page_alloc         11528  2 snd_intel8x0,snd_pcm

Anyway, now with the xorg.cong attached, now it seems all is working well (with Option "AccelMethod" "XAA", if i use EXA everything is really slow)!!


g4b0@slack:~$ x11perf -aa10text
x11perf - X11 performance program, version 1.2
The X.Org Foundation server version 10402000 on :0.0
from slack
Thu Oct  2 10:37:52 2008

Sync time adjustment is 0.0734 msecs.

 240000 reps @   0.0226 msec ( 44200.0/sec): Char in 80-char aa line (Charter 10)
 240000 reps @   0.0241 msec ( 41600.0/sec): Char in 80-char aa line (Charter 10)
 240000 reps @   0.0251 msec ( 39800.0/sec): Char in 80-char aa line (Charter 10)
 240000 reps @   0.0264 msec ( 37900.0/sec): Char in 80-char aa line (Charter 10)
 240000 reps @   0.0271 msec ( 36900.0/sec): Char in 80-char aa line (Charter 10)
1200000 trep @   0.0251 msec ( 39900.0/sec): Char in 80-char aa line (Charter 10)

Created attachment 19334 [details]
My working xorg.conf on a 82865G

openSUSE 11
Chipset 865G
2.6.25.16-0.1-default
xorg-x11 7.3-96.2
xserver 1.4.0.90
xorg-x11-driver-video 7.3-138.5
intel 2.3.1
KDE 4.1.2

I have had the same performance problems when I installed XOrg 7.4 a few days ago from the same repository as René 
http://download.opensuse.org/repositories/X11:/XOrg/openSUSE_11.0/
the intel driver was also 2.4.97

With the normal setup (XOrg 7.3, Xserver 1.4.0.90, intel 2.3.1) without composition and I think with xaa (since Jul 28 for openSUSE 11) the performance is normal.

Mon 28 Jul 2008 07:00:00 AM ECT
sndirsch@suse.de
- xf86-video-intel-default2xaa.diff
  * due to serious overall performance regressions switch back to
  XAA for intel driver again (bnc #411183)


goetz@fortaleza:~> x11perf -aa10text
x11perf - X11 performance program, version 1.2
The X.Org Foundation server version 10400090 on :0.0
from fortaleza
Sun Oct  5 17:24:22 2008

Sync time adjustment is 0.0489 msecs.

 560000 reps @   0.0093 msec (108000.0/sec): Char in 80-char aa line (Charter 10)
 560000 reps @   0.0093 msec (108000.0/sec): Char in 80-char aa line (Charter 10)
 560000 reps @   0.0093 msec (108000.0/sec): Char in 80-char aa line (Charter 10)
 560000 reps @   0.0094 msec (106000.0/sec): Char in 80-char aa line (Charter 10)
 560000 reps @   0.0091 msec (109000.0/sec): Char in 80-char aa line (Charter 10)
2800000 trep @   0.0093 msec (108000.0/sec): Char in 80-char aa line (Charter 10)

René, Götz, could you give the latest intel driver a try? I just submitted a package for the buildservice. 

  http://download.opensuse.org/repositories/X11:/XOrg/

Make sure that the RPM changelog ("rpm --changelog -qp xorg-x11-driver-video.rpm") contains:

-------------------------------------------------------------------
Tue Oct  7 12:34:44 CEST 2008 - sndirsch@suse.de

- xf86-video-intel 2.4.97.0_2.5-branch_979bb10
  * latest git commit of 2.5-branch
- obsoletes xf86-video-intel-commit-fa2586a.diff

(In reply to comment #15)
> René, Götz, could you give the latest intel driver a try? I just submitted a
> package for the buildservice. 
...
> - xf86-video-intel 2.4.97.0_2.5-branch_979bb10
>   * latest git commit of 2.5-branch
> - obsoletes xf86-video-intel-commit-fa2586a.diff

Hi Stefan,

While it's always helpful for users to test the latest stuff, I don't see any changes between fa2586a and 979bb10 that we should expect to make any performance difference here.

I got my hands on an 865 machine yesterday, so if I can get it to boot then I'll try replicating the bug tomorrow.

-Carl

Carl, xf86-video-intel-commit-fa2586a.diff was a patch for commit fa2586a, not a patch, which updates the driver to commit fa2586a. The new package updates the driver from git commit 8408995 (Intel-2008-Q3-RC2 release) to git commit 979bb10.

Quanxian asked me to test the latest git commit. Unfortunately I don't have a 865G machine for testing available.

I found a Dell Dimension 1100 and grab a latest OpenSuSE 11.1 Beta2 LiveCD, and I can't reproduce this bug. I visited heise.de site and do scrolling with no problem.

I used Rene's xorg.conf in comment# 1. 

Created attachment 19473 [details]
Xorg.0.log

Created attachment 19474 [details]
lspci

Created attachment 19475 [details]
uname -a

(In reply to comment #19)
> I found a Dell Dimension 1100 and grab a latest OpenSuSE 11.1 Beta2 LiveCD, and
> I can't reproduce this bug. I visited heise.de site and do scrolling with no
> problem.
> 
> I used Rene's xorg.conf in comment# 1. 

Thanks, very interesting. I'm about to grab the 11.1 Beta2 LiveCD, too, and will try it a.s.a.p. on the same hardware for which I reported this.

(In reply to comment #15)
> René, Götz, could you give the latest intel driver a try? I just submitted a
> package for the buildservice. 
> [..]

I got a new package from Stefan because the packages hasn't been arrived on the OpenSUSE mirrors from Oct 7th with the described changelog. Only XAA works performantly again.

Unfortunately even this package has no effect on this issue in OpenSUSE 11.0. But there are also news, I will answer to another comment inside here...

(In reply to comment #19)
> I found a Dell Dimension 1100 and grab a latest OpenSuSE 11.1 Beta2 LiveCD, and
> I can't reproduce this bug. I visited heise.de site and do scrolling with no
> problem.
> 
> I used Rene's xorg.conf in comment# 1. 
> 

That's the news, good hint. That works even for me, using the OpenSuSE 11.1 Beta2 LiveCD. For being absolutely sure I checked at first the performance with the auto-generated xorg.conf and later with the mentioned xorg.conf I previously attached. EXA works in OpenSUSE 11.1 Beta (LiveCD) with a slightly good performance, there are no problems here anymore I have seen for now!

Furthermore, I too the auto-generated xorg.conf from the 11.1 Beta2 and used it back in OpenSUSE 11.0, and voila, there are the same problems as before.

I will attach files later.

So what is wrong with OpenSUSE 11.0 against 11.1 Beta2, where's the relevant difference for this here?

Created attachment 19486 [details]
xorg.conf auto-generated in OpenSUSE 11.1 Beta2

The auto-generated xorg.conf attached here works good for OpenSUSE 11.1 Beta 2, but there are the same problems with it as before in OpenSUSE 11.0.

Created attachment 19488 [details]
Xorg.0.log in OpenSUSE 11.1 Beta 2 (using the previously attached xorg.conf)

Don't know. If you have the latest intel driver bits (libdrm, Mesa, xorg-x11-server, xorg-x11-driver-video) from X11:XOrg project and use the same xorg.conf, it can only be the kernel of openSUSE 11.0.

(In reply to comment #28)
> Don't know. If you have the latest intel driver bits (libdrm, Mesa,
> xorg-x11-server, xorg-x11-driver-video) from X11:XOrg project and use the same
> xorg.conf, it can only be the kernel of openSUSE 11.0.
> 

Comparing Xorg.0.log in both, the 11.0 and 11.1 Beta 2 does not show differences in any version number within Xorg, only the kernel is newer, that's true. Strange.

@Götz: Are you able to check this for the OpenSUSE 11.1 Beta LiveCD, too? That would make it more sure. It probably will be enough to just launch it with the auto-generated X configuration and directly test with Konqueror on heise.de, for instance.

@Carl: This will probably be a hard nut to crack. It would be very interesting what happened on your 865G launching it with kernel 2.6.25.16 (the latest update version in OpenSUSE 11.0) on Debian. Doesn't it make sense to give it a try?

Like said before, there isn't any xorg-x11-driver-video from 7 October with that change log in this /repositories/X11:/XOrg/ repo.

@René I will download openSUSE 11.1 Beta 2, and post again when I finish the test.

I'm glad to hear that the performance is better with the kernel that's in 11.1 Beta 2 release. What kernel version is that?

I wasn't able to test with my 865 machine today, but I still plan to do that tomorrow. But it sounds more than ever like the bug here is fixed already, (even if we don't know exactly what the performance problem was yet).

-Carl

Kernel on openSUSE 11.1 Beta2 is 2.6.27-rc6. on openSUSE 11.0 is kernel 2.6.25.16. None of these kernels include any GEM patches.

(In reply to comment #33)
> Kernel on openSUSE 11.1 Beta2 is 2.6.27-rc6. on openSUSE 11.0 is kernel
> 2.6.25.16. None of these kernels include any GEM patches.

Thanks for those details. There aren't a *lot* of changes between those two kernel versions. One possibility is that the MTRR setup was just wrong on the old kernel, (giving slow, uncached software fallbacks). It would be helpful if someone could provide the output of:

    cat /proc/mtrr

on a system with both kernels, (one showing the performance bug, and one not showing it). Hopefully that will let us verify this theory.

Thanks,

-Carl

Created attachment 19556 [details]
Hopefully all relevant files for both OpenSUSE distributions

@Carl: Ok, here is the one from me. In the attached archive you can find the following files for analyzing from both distributions:
- output of cat /proc/mtrr
- output of lsmod
- output of glxinfo
- output of uname -a
- output of lspci
- output of rpm -qa|egrep 'xorg|Mesa|drm'|sort
  (the relevant packages from the distribution for Xorg)

Additionally, there are again the Xorg.0.log and xorg.conf for the OpenSUSE 11.1 Beta2 LiveCD.

OpenSUSE 11.1 Beta2 with kernel 2.6.27 works performantly with EXA, I checked this again.

Looks like the MTRR settings are the same with both kernels.

reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
reg01: base=0x7f800000 (2040MB), size=   8MB: uncachable, count=1
reg02: base=0xf0000000 (3840MB), size= 128MB: write-combining, count=1

Created attachment 19608 [details]
xorg.conf, /proc/mtrr, x11perf -aa10text

I have now tested openSUSE 11.1 Beta 2. 
The scrolling performance in heise.de was normal, a bit slow. But the overall performance in KDE 4.1.2 was slow (with live CD). 
Kwin composition wouldn't start, but Compiz has started but it was also slow.

After that I tested in my system (openSUSE 11.0) with exa (only with MigrationHeuristic greedy) kwin composition also wouldn't start with this message:

Failed to activate desktop effects using the given configuration options. Settings will be reverted to their previous values.
Check your X configuration. You may also consider changing advanced options, especially changing the compositing type.

Also Compiz was very slow with MigrationHeuristic greedy, only with exa the whole performance was better.


  OPENSUSE 11.1 BETA 2 - exa
x11perf -aa10text
49500.0/sec

  OPENSUSE 11.1 BETA 2 - exa "MigrationHeuristic" "greedy"
x11perf -aa10text
95000.0/sec

  OPENSUSE 11.1 BETA 2 - xaa
x11perf -aa10text
118000.0/sec

  OPENSUSE 11.0 - exa
x11perf -aa10text
90000.0/sec

  OPENSUSE 11.0 - exa "MigrationHeuristic" "greedy"
x11perf -aa10text
19000.0/sec

  OPENSUSE 11.0 - xaa
x11perf -aa10text
112000.0/sec

Both /proc/mtrr were the same in openSUSE 11.1 Beta 2 and openSUSE 11.0

goetz@fortaleza:~> cat /proc/mtrr
reg00: base=0x00000000 (   0MB), size=1024MB: write-back, count=1
reg01: base=0x40000000 (1024MB), size= 512MB: write-back, count=1
reg02: base=0x5f800000 (1528MB), size=   8MB: uncachable, count=1
reg03: base=0xf0000000 (3840MB), size= 128MB: write-combining, count=1

The xorg.conf files were not so different. So, for me xaa work faster in both systems, with exa and MigrationHeuristic greedy I was not able to run Kwin compositor.

I have attached some outputs.

(In reply to comment #36)
> Looks like the MTRR settings are the same with both kernels.
> [..]

Yes, I noticed this also.

What about other shared libraries glibc the driver is linked with, especially glibc. Can't there be some optimizations somewhere from 11.0 to 11.1 Beta2? I found the following libraries that intel_drv.so is linked with:
libm.so.6
libpciaccess.so.0
libdrm.so.2
libdrm_intel.so.1
libc.so.6

And what about the planned kernel optimizations and features in 2.6.26 and 2.6.27, locking and so on?

I'm curious if there are differences at Carl's Debian box between the two kernels. I guess there will be also some.

No news even with the latest video drivers from OpenSUSE build service:
* Thu Oct 09 2008 sndirsch@suse.de
- xf86-video-intel 2.4.97.0_2.5-branch_ffcbbb0
  * Intel-2008-Q3-RC3 release

BTW: Except the slow scrolling I noticed also the whole time since I started this report that overall performance and start of KDE4 with EXA on openSUSE 11.0 (kernel 2.6.25) is slightly slower than XAA, the systray, painting the panels in applications as kmail. Not to forget the already mentioned slight flickering on starting X server (switching to KDM logon) with the uninitialized screen with distorted patterns for some moment using EXA, with XAA there is no visible flickering at all and switching goes fluently.

Will the performance increse with a GEM Kernel and EXA like said in bug 13389?

http://bugs.freedesktop.org/show_bug.cgi?id=13389

I would like to compile a Kernel with the GEM patches. Or is it better to wait until 2.6.28 RC?

Nothing new even with the latest precompiled drivers for OpenSUSE 11.0:
- libdrm 2.4.0
---
Sun 19 Oct 2008 02:00:00 PM CEST
sndirsch@suse.de
- libdrm 2.4.0 finally available
---

- xf86-video-intel 2.4.98
Changelog:
---
Sun 19 Oct 2008 02:00:00 PM CEST
sndirsch@suse.de
- xf86-video-intel 2.4.98
  * smoke test for 2.5.0 release planned for Mon Oct 20
- obsoletes xf86-video-intel-vbe_noinit.diff
- obsoletes xf86-video-intel-crt-mode-fix.diff
---

(In reply to comment #39)
> BTW: Except the slow scrolling I noticed also the whole time since I started
> this report that overall performance and start of KDE4 with EXA on openSUSE
> 11.0 (kernel 2.6.25) is slightly slower than XAA, the systray, painting the
> panels in applications as kmail. Not to forget the already mentioned slight
> flickering on starting X server (switching to KDM logon) with the uninitialized
> screen with distorted patterns for some moment using EXA, with XAA there is no
> visible flickering at all and switching goes fluently.

There are lots of different issues mentioned above. And I know you care about each of them. So, to do each justice, will you please open a separate bug report for each one so that we can track each independently?

From my reading here, the original "slow scrolling" bug appears to be fixed after a change in the OpenSUSE kernel. We didn't figure out exactly what that change was, (the first guess of MTRRs appears to not be correct). But I am happy that the slow scrolling is now better.

Thanks,

-Carl

(In reply to comment #37)
> I have now tested openSUSE 11.1 Beta 2. 
> The scrolling performance in heise.de was normal, a bit slow.

I'm glad the scrolling performance is better now. That's why I've marked this bug as resolved.

> But the overall
> performance in KDE 4.1.2 was slow (with live CD). 
> Kwin composition wouldn't start, but Compiz has started but it was also slow.

Let's investigate these issues with new bug reports, please.
 
> After that I tested in my system (openSUSE 11.0) with exa (only with
> MigrationHeuristic greedy) kwin composition also wouldn't start with this
> message:

Using MigrationHeuristic=greedy is really uninteresting. It may make some things better, but it will also make other things much worse. We know that it's a dead end, so we don't have any interest in exploring it further.

>   OPENSUSE 11.1 BETA 2 - exa
> x11perf -aa10text
> 49500.0/sec
> 
>   OPENSUSE 11.1 BETA 2 - xaa
> x11perf -aa10text
> 118000.0/sec
> 
>   OPENSUSE 11.0 - exa
> x11perf -aa10text
> 90000.0/sec
>
>   OPENSUSE 11.0 - xaa
> x11perf -aa10text
> 112000.0/sec

Thanks for reporting these detailed benchmark results. They could be useful for tracking down a separate issue, (such as "slow text rendering" instead of "slow scrolling").

The things you'll want to do here are to find if the benchmark result correlates with the broader symptom that you're trying to diagnose.

Also, the result above shows that OpenSUSE 11.0 EXA is twice as fast as OpenSUSU 11.1 BETA2 EXA. That's an interesting result, but very different than the original "slow scrolling" bug we were tracking here.

The next step in pursuing that issue would be to identify relevant component version differences, (kernel, X server, X server driver, etc.), between the two systems and try swapping them individually until the relevant component can be identified. That could lead to a report such as "Component X at version Y leads to a 50% reduction in text rendering performance".

I'll look forward to more details here.

> Both /proc/mtrr were the same in openSUSE 11.1 Beta 2 and openSUSE 11.0

Yes, thanks for checking. So that was one theory on how the kernel change could have been relevant that's proven incorrect.

At this point, there's nothing obvious in the kernel differences. So the differences between 11.0 and 11.1 Beta 2 could be either a subtle kernel difference, or perhaps more likely something not kernel related at all.

-Carl

Although this is marked fixed I'd like to add a small information update:
The EXA acceleration still doesn't work performantly for me even with the latest updates in OpenSUSE 11.0, which are:
- kernel-default-2.6.25.18-0.2 (latest update)
- libdrm-2.4.0-14.1
- xorg-x11-driver-video-7.4-18.4
- xorg-x11-server-7.4-11.5
- Mesa-7.2-6.4
which contains:
- X.Org X Server 1.5.2, Release Date: 10 October 2008
- (II) Module intel: vendor="X.Org Foundation"
        compiled for 1.5.2, module version = 2.5.0
        Module class: X.Org Video Driver
        ABI class: X.Org Video Driver, version 4.1

`cat /proc/mtrr`:
reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1
reg01: base=0x7f800000 (2040MB), size=   8MB: uncachable, count=1
reg02: base=0xf0000000 (3840MB), size= 128MB: write-combining, count=1

If I got it right, this issue seems not to be a blocker for distributions with kernel 2.6.27, but for users with stable distributions, the solution seems to be now: Be patient and wait for a new distribution with kernel 2.6.27.

Furthermore, especially for OpenSUSE 11.0 this probably means keeping the XAA code as long as possible in the Intel video drivers. Am I right?

Created attachment 19975 [details]
The diagnostic files after applying the latest OpenSUSE 11.0 updates

After updating to the latest OpenSUSE 11.0 patches (among others libdrm 2.4.1) there is the same performance leak in EXA with kernel 2.6.25 as the whole time. I attached the diagnostic files. Only XAA works good.

I really don't like to riddle with stuff marked done, but the problem reappeared for me even with kernel 2.6.27.4 in OpenSUSE 11.1 Beta4, which I installed formatting my old OpenSUSE 11.0 root partition. Again the same problem, the overall performance is slow with EXA as seen with the beginning of this report, XAA works fluently, instead. I still don't want to reopen this, because I'm not sure whether this is distribution-specific or not. Fortunately, MigrationHeuristic XAA still works.

Created attachment 20213 [details]
Xorg.0.log with XAA on OpenSUSE 11.1 (for you to see the Xorg and driver versions)

On my Thinkpad X60s I just "upgraded" from Ubuntu Hardy Heron (Kernel version to OpenSUSE 11.1. 

Unfortunately this update turned out to be a downgrade partially due to this bug which according to the inital reporter has apparently not been sufficiently dealt with.

I'm the developer of the application Marble (http://edu.kde.org/marble) which mostly relies on "pumping" pixmaps up to the X-Server (which is the only way for me to ensure that this application at least "kind of" works everywhere).

With Hardy heron (EXA and in hindsight I suppose that MigrationHeuristics was turned on by the distributor) I had a framerate of 

18.2 fps 

at full screen. With the current OpenSUSE 11.1 I get about 

4 fps. 

Also the KDE 4.2 desktop that I've just installed shows a significant lack of responsiveness.

Enabling the MigrationHeuristics gets the Marble performance up to about 13 fps. That isn't quite as good as the previous results but closer to an acceptable performance. Also the whole desktop becomes quite snappy after this change.





  





 

BTW: If you'd like to verify the performance you can start Marble with "marble --fps". I'd suggest to zoom in until the whole earth covers the viewport (as only then the full viewport gets changed for each frame).

Regards,
Torsten Rahn

(In reply to comment #48)
> On my Thinkpad X60s I just "upgraded" from Ubuntu Hardy Heron (Kernel version
> to OpenSUSE 11.1. 

That sentence should read:

On my Thinkpad X60s I just "upgraded" from Ubuntu Hardy Heron, XOrg version:

X.Org X Server 1.4.0.90
Release Date: 5 September 2007
X Protocol Version 11, Revision 0
Build Operating System: Linux Ubuntu (xorg-server 2:1.4.1~git20080131-1ubuntu9.2)
Current Operating System: Linux tackat-laptop 2.6.24-19-generic #1 SMP Wed Aug 20 22:56:21 UTC 2008 i686
Build Date: 13 June 2008  01:08:21AM

to OpenSUSE 11.1, XOrg version:

X.Org X Server 1.5.2
Release Date: 10 October 2008
X Protocol Version 11, Revision 0
Build Operating System: openSUSE SUSE LINUX
Current Operating System: Linux linux-zdp8 2.6.27.7-9-pae #1 SMP 2008-12-04 18:10:04 +0100 i686
Build Date: 03 December 2008  09:21:06AM

... just in case you were wondering what I might have forgot to tell you.
Also regarding the "MigrationHeuristics greedy" topic there's 

https://bugs.launchpad.net/xserver-xorg-video-intel/+bug/177492

which doesn't exactly convey the idea that this issue is "resolved" yet. :-)

(In reply to comment #48) 
> With Hardy heron (EXA and in hindsight I suppose that MigrationHeuristics was
> turned on by the distributor) I had a framerate of 
> 
> 18.2 fps 
> 
> at full screen. With the current OpenSUSE 11.1 I get about 
> 
> 4 fps. 
> 
> Also the KDE 4.2 desktop that I've just installed shows a significant lack of
> responsiveness.
> 
> Enabling the MigrationHeuristics gets the Marble performance up to about 13
> fps. That isn't quite as good as the previous results but closer to an
> acceptable performance. Also the whole desktop becomes quite snappy after this
> change.

Hi Torsten,

For MigrationHeuristics, "turned on" and "enabling" doesn't mean anything. This is not a Boolean option but an option that can have many different values. Your report would be much more meaningful if you said which values you were using that were both slow and faster.

The original report was for an 865 graphics device. Is that also what you are using? Also, what version of the Intel drivers?

Finally, since you've got a system that you can change from "unacceptably slow" to "tolerable speed (though still not ideal)" by changing an option, then it would be great if you could identify any x11perf test cases that similarly respond to the same option change. It sounds like you've got a good understanding of what your application does, (and that it's fairly simple with respect to X operations), so hopefully you can easily find an x11perf test case that corresponds to it.

I'll look forward to more from you,

-Carl

PS. With as long as a bug report like this one is, and with as many different issues are already mentioned here, I'd *still* prefer to see new issues discussed on new bug reports, (even if the symptoms are fairly similar). No big deal though.

from my experience its often hard to catch such performance problems with X11, because it doesn't suffer from migration overhead.

Typical apps usually do a lot of different operations mixed, and if 5% of them cause  a fallback performance is horrible.

sorry, ment X11perf of course

René,

This is a pretty old bug report, (and I'm not even sure that you are the one that reopened it). We didn't determine the exact problem, but we also didn't determine that the bug was not SuSe-specific, (we did get one report of someone with identical hardware that wasn't able to reproduce the bug).

In the meantime, however, the driver has moved on quite a lot, (particularly with kernel 2.6.30 and also xf86-video-intel 2.7.x).

Enough has changed that I'm going to re-close this bug.

René, if you can test a more recent version of the driver and if you still see the bad performance, then please reopen this bug, and I will be glad to investigate the issue further.

For anyone else who reported a similar issue on this bug, please open a new report for your issue (and also if it exists with recent driver versions).

Thanks,

-Carl