Bug 18389

Since Kent asked me about the severity/priority.

Yes, let's focus on EXA bug.

The novell link needs login. Please provide the info according to http://intellinuxgraphics.org/how_to_report_bug.html. 

Here is some additional information, I will post logs and configs shortly:

- chipset: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)
-- system architecture: x86_64
-- xf86-video-intel/xserver/mesa/drm version: xorg-x11-driver-video-7.4-13.1, xorg-x11-7.4-8.2, xorg-x11-server-7.4-11.1, Mesa-7.2-5.5, libdrm-2.4.0-12.4
-- kernel version: 2.6.27.4-2-default
-- Linux distribution: SUSE Linux Enterprise Desktop 11 beta4 (Same as OpenSUSE 11.1 beta 4)
-- Machine or mobo model: Lenovo Thinkpad T61 (SLED Preload Model)
-- Display connector: Onboard LCD and external VGA

Created attachment 20131 [details]
Output of dmesg

Created attachment 20132 [details]
xorg.conf for using XAA

I just added the XAA support in the Device section, if I remove it I'm back to EXA (default)

Created attachment 20133 [details]
Xorg log using EXA

Created attachment 20134 [details]
Xorg log for using EXA

(In reply to comment #0)
> I'm running the latest OpenSUSE 11.1 beta (SLED 11 beta really) and have to
> face a cruel choice between very poor window drawing performance with EXA
> (https://bugzilla.novell.com/show_bug.cgi?id=438266)

Hi Dan,

Thanks for reporting this bug. I can't see anything from the novell.com link above, (just get prompted for a username and password), so could you share some details with me?

Specifically, if I were to attempt reproduce this bug, how would I know if were seeing it or not?

I'm guessing that the x86_64 piece might be relevant, and the kernel version is likely very significant. Here's a review of some of the details, (with the actual component versions from the logs rather than the xorg 7.4 numbers):

Architecture: x86_64
Kernel: 2.6.27.4
libdrm: 2.4.0
X server: 1.5.2
xf86-video-intel: 2.4.97

(All OpenSUSE packages of course.)

I'll see if I can get a system running something close to that soon, (though I'll be out of town for the next week).

-Carl

Hi Carl,
The issue I'm seeing with EXA is that window drawing (2d) performance is very slow to the point where it feels like I'm using a very old system with a vesa driver.  Minimizing, maximizing, or dragging windows around is laggy.  Not unusable slow, but probably a good 10 times slower than with XAA.  I don't have the desktop effects enabled (although I believe AIGLX is turned on).  I don't know of a good way to benchmark window drawing performance but I would be happy to provide some hard numbers instead of my subjective "goes slow" statement if there's a better way.  There was a Video BIOS update for the T61
(http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-67988)
that I installed to see if it helped but it didn't.  From
the release notes:

"(Fix) Intel GM965 Video BIOS was updated to v1668 to fix a blue screen error
issue on the Windows Vista."

Just let me know what additional information I can provide.
Thanks,
Dan

On Fri, 2008-11-07 at 11:12 -0800, Dan Elder wrote:
> The issue I'm seeing with EXA is that window drawing (2d) performance is very
> slow to the point where it feels like I'm using a very old system with a vesa
> driver.  Minimizing, maximizing, or dragging windows around is laggy.  Not
> unusable slow, but probably a good 10 times slower than with XAA.

Thanks. There's a little more detail in there which is useful.

What we really want to figure out next is what operation is being asked
for here, which gets us to...

>   I don't have
> the desktop effects enabled (although I believe AIGLX is turned on).

The real question here is whether or not there's a compositing manager
running. One some distributions, (such as Fedora, I believe), by default
there's no compositing manager running, (just metacity without its
builting compositing support), and then if you turn on "desktop effects"
it runs compiz. That may or may not be the same with OpenSUSE.

But better than just knowing "yes, there's a compositing manager
running" would be to find a benchmark score that actually changes in a
manner that correlates with the behavior you are seeing.

For example, if the slow operation here is straight blitting, (window
copying without blending), then you could run something like:

	x11perf -copypixwin500

or so under both XAA and EXA to see if the scores change in a manner
similar to your bug. When you find an x11perf test case that changes
with XAA and EXA then we've hit the jackpot and debugging gets *much*
easier from there.

I'm suspecting that compositing is actually happening here, not just
copying. In old versions of x11perf there weren't any compositing tests.
If you've got a sufficiently new x11perf then you can do something like:

	x11perf -comppixwin500

I'm not 100% sure that that test is doing something entirely useful, (it
does seem to call the right blending functions but with apparently no
alpha channels).

Anyway, any details you might be able to provide would be great.

-Carl

I think I can provide some more information about the software installation.
openSUSE 11.1 Beta4 comes with

- xorg-server 1.5.2
- xf86-video-intel 2.5.0
- libdrm: commit a59ea02 (Intel-2008-Q3-RC5)
- Mesa 7.2_intel-2008-q3_46921a5 (Intel-2008-Q3-RC5)

Kernel is 2.6.27.4 *without* any GEM patches applied.

(In reply to comment #11)
> I think I can provide some more information about the software installation.
> openSUSE 11.1 Beta4 comes with

Thanks Stefan.

Those are helpful details with respect to versions, etc.

Do you or anyone else here happen to know if OpenSUSE 11.1 Beta4 is using a compositing manager by default? (That is, without enabling "desktop effects".)

-Carl

I've been able to find a few specific tests that are significantly faster under XAA than under EXA.  With XAA I have:

 20000 reps @   0.3915 msec (  2550.0/sec): 500x500 stippled rectangle (8x8 stipple)

With EXA I have :

   2000 reps @   4.6828 msec (   214.0/sec): 500x500 stippled rectangle (8x8 stipple)

There's a lot of places where EXA is faster than XAA as well but I'll upload my full results from each.  I had a system crash during the EXA test (unrelated to video) so I don't have full results but hopefully this sheds some light.

Created attachment 20143 [details]
x11perf -all -repeat 2 with EXA enabled

Created attachment 20144 [details]
x11perf -all -repeat 2 with XAA enabled

Carl, I'm not sure if a compositing manager is started by default on openSUSE 11.1 Beta4. 

AFAIK Gnome uses compiz if desktop effects have been enabled. In KDE4 the compositing manager is integrated (into kwin?). 

There were some discussions to enable desktop effects by default for a whitelist of drivers depending on the graphics chip in use. It might be
enabled for 965GM by default. 

Anyway, Dan said in the Novell Bugzilla report and in this one as well that he has desktop effects not enabled.

BTW, I noticed that Composite extension has not been enabled at all through
xorg.conf.

  Section "Extensions"
    Option       "Composite" "on"
  EndSection

is missing in Dan's xorg.conf. Have this extension enabled is not the default
of xorg-server 1.5.2.

(In reply to comment #16)
> Anyway, Dan said in the Novell Bugzilla report and in this one as well that he
> has desktop effects not enabled.

When there's a problem without a compositing manager, does running something like xcompmgr -a improve things with EXA? Without a compositing manager, some of the x11perf tests with very low numbers involve read-modify-write cycles to uncached memory...

> BTW, I noticed that Composite extension has not been enabled at all through
> xorg.conf.

It's been enabled by default for a while, 1.4 if not earlier.

(In reply to comment #17)
> > BTW, I noticed that Composite extension has not been enabled at all
> > through xorg.conf.
> 
> It's been enabled by default for a while, 1.4 if not earlier.

I'm not sure. I'm seing

  (**) Extension "Composite" is enabled
  [...]
  (II) Initializing built-in extension COMPOSITE

in Xserver's logfile with this option, but only

  (II) Initializing built-in extension COMPOSITE

without it.

(In reply to comment #18)
>   (II) Initializing built-in extension COMPOSITE

I'm only getting that as well when it's enabled by default. Check with

xdpyinfo|grep Composite

to be sure.

Michael, you're right. Sorry for the confusion.

Created attachment 20194 [details]
Screenshot of graphics corruption

One other weird issue I have when using EXA but not XAA is that I'll get graphical corruption in my Groupwise client text.  This is a java application and I'm currently using the following JRE:

java version "1.6.0"
Java(TM) SE Runtime Environment (build pxa6460sr2-20080818_01(SR2))
IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Linux amd64-64 jvmxa6460-20080816_22093 (JIT enabled, AOT enabled)
J9VM - 20080816_022093_LHdSMr
JIT  - r9_20080721_1330ifx2
GC   - 20080724_AA)
JCL  - 20080808_02

Scrolling around in the app or clicking anywhere probably forces a screen refresh which clears it up but eventually (without user interaction) it will come back.

The following Ubuntu bug report seems to be the same issue (or at least related to the same hardware):

https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/252094

Any progress for that?

(In reply to comment #13)
> There's a lot of places where EXA is faster than XAA as well but I'll upload my
> full results from each.  I had a system crash during the EXA test (unrelated to
> video) so I don't have full results but hopefully this sheds some light.

Dan,

Thanks for posting the results from this performance testing. There's definitely something interesting to see in the results from the 4 variants of the copy tests (shown below for the 10x10 tests and the 500x500 tests).

For most of the EXA tests the performance is basically unchanged when changing from 10x10 to 500x500. That suggests that there is good GPU acceleration happening. Contrast that with the XAA results where performance generally falls dramatically from 10x10 to 500x500 suggesting that the CPU is getting involved on a per-pixel basis.

The big exception is the pixmap to pixmap test where not only does EXA get dramatically slower from 10x10 to 500x500, but it's also from 2x to 14x slower than XAA for this case. So there's obviously something quite broken there, (perhaps migration for a fallback).

If you've got a recent xf86-video-intel driver (from git) then you can turn on the following option (in the device section of your xorg.conf file):

    Option "FallbackDebug" "true"

and then check your Xorg.#.log file to see if there are fallbacks that correspond to the slow behavior you're seeing.

-Carl

EXA
===
winwin:  10: 1370000
        500: 1330000

pixwin:  10: 1570000
        500: 1550000

winpix:  10: 1420000
        500: 1400000

pixpix:  10:   83700
        500:    1740

XAA
===
winwin:  10:  280000
        500:    1730

pixwin:  10:  206000
        500:     247

winpix:  10:   65100
        500:      52

pixpix:  10: 1210000
        500:    4380

(In reply to comment #24)
> For most of the EXA tests the performance is basically unchanged when changing
> from 10x10 to 500x500. That suggests that there is good GPU acceleration
> happening. Contrast that with the XAA results where performance generally falls
> dramatically from 10x10 to 500x500 suggesting that the CPU is getting involved
> on a per-pixel basis.

I got some details wrong above.

We do expect substantial slowdown between the 10x10 and 500x500 tests. And in fact, the original numbers reported here are basically physically impossible. The expected results are about 1000 operations per second for the 500x500 case (based on available memory bandwidth) and about 125000 to 250000 operations per second for the 10x10 case (limited this time by the maximum rate of command submission).

So something went wrong in testing that you saw such impossibly large numbers. 

> The big exception is the pixmap to pixmap test where not only does EXA get
> dramatically slower from 10x10 to 500x500, but it's also from 2x to 14x slower
> than XAA for this case. So there's obviously something quite broken there,
> (perhaps migration for a fallback).

It still looks like there is a problem in this case. I'm still looking to see
if I can replicate this.

-Carl

I've done some testing with OpenSUSE 11.1 Beta5 (the KDE4 LiveCD) and identified some performance issues. I haven't done comparisons with XAA yet, but instead compared performance against my standard development build. This currently consists of:

Linux 2.6.28-rc4 (from git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel for-review branch)
X server 1.5.99.1 (recent master)
xf86-video-intel 2.4.97 (recent master)

For testing I took x11perf with a selected set of tests (eliminating all of the uninteresting core rendering tests such as stippled fills, wide lines, ellipses, and arcs). I ran these tests against my "master" builds and then the same tests on the same hardware after booting the OpenSUSE live CD.

Finally, I manually scanned the results looking for cases where the performance differed by 2x or more. Below is a sorted list of the differences, showing the "master" performance followed by the OpenSUSE performance for each test. Also, for each test the relative performance is quantified (where "slowdown" means that the OpenSUSE performance is slower than the "master" performance---note that in two cases there is actually a speedup instead).

The next step would be to do profiling of some of the slowest tests, or perhaps to switch out one or more components to see what's contributing to the performance difference. Any contribution to those efforts from anyone would be most appreciated---as would any verification of these test results, or similar testing with XAA.

The copywinwin test is likely the most fundamental. And it perhaps is at the root of several of the other slowdowns.

Here's an x11perf command line that can be used to quickly obtain results for just these tests that seem interesting:

x11perf -repeat 2 \
  -aatrap1 -aatrap10 -aatrap2x1 -aatrap2x10 \
  -aa10text -aa24text -rgb10text -rgb24text \
  -scroll10 -scroll100 \
  -copywinwin10 -copywinwin100 \
  -copypixwin10 -copypixwin100 \
  -putimage10 -putimage100 \
  -shmput10 -shmput100 \
  -getimage100 -getimage500 \
  -compwinwin10 -compwinwin100 \
  -comppixwin10 -comppixwin100

And here are the results I obtained:

-aatrap2x1:     316000.0/sec
                 70900.0/sec    44.5x slowdown

-putimage10:    126000.0/sec
                  6280.0/sec    20.1x slowdown

-copywinwin10:  137000.0/sec
                  7570.0/sec    18.1x slowdown

-compwinwin10:  125000.0/sec
                  7520.0/sec    16.6x slowdown

-comppixwin10:  124000.0/sec
                  8360.0/sec    14.8x slowdown

-copypixwin10:  125000.0/sec
                 10000.0/sec    12.5x slowdown

-scroll10:      139000.0/sec
                 11500.0/sec    12.1x slowdown

-shmput10:      112000.0/sec
                 10700.0/sec    10.5x slowdown

-getimage100:     1350.0/sec
                  6240.0/sec     4.6x speedup (!)

-putimage100:     9420.0/sec
                  2260.0/sec     4.2x slowdown

-aatrap1:       325000.0/sec
                 79700.0/sec     4.1x slowdown

-aa24text:       57700.0/sec
                 14600.0/sec     4.0x slowdown

-shmput100:      14900.0/sec
                  4270.0/sec     3.5x slowdown

-aatrap10:       89800.0/sec
                 25400.0/sec     3.5x slowdown

-copywinwin100:  19100.0/sec
                  5750.0/sec     3.3x slowdown

-compwinwin100:  19100.0/sec
                  5730.0/sec     3.3x slowdown

-aa10text:       85100.0/sec
                 26200.0/sec     3.2x slowdown

-rgb10text:      76200.0/sec
                 24900.0/sec     3.0x slowdown

-comppixwin100:  18200.0/sec
                  6280.0/sec     2.9x slowdown

-scroll100:      19000.0/sec
                  6850.0/sec     2.8x slowdown

-aatrap2x10:     97000.0/sec
                 35200.0/sec     2.8x slowdown

-rgb24text:      45200.0/sec
                 16800.0/sec     2.7x slowdown

-copypixwin100:  18400.0/sec
                  6750.0/sec     2.7x slowdown

-shmput500:       1070.0/sec
                   420.0/sec     2.5x slowdown

-putimage500:      394.0/sec
                   161.0/sec     2.4x slowdown

-getimage500:       55.8/sec
                   106.0/sec     1.9x speedup (!)

(In reply to comment #26)
> I've done some testing with OpenSUSE 11.1 Beta5 (the KDE4 LiveCD) and
> identified some performance issues.

As described in comment #26, the performance problems appear to exist in OpenSUSE 11.1 Beta5 but not in the xf86-video-intel code which is currently a release candidate for the upcoming 2.6 release.

So whatever the bug is, it appears to be fixed in the current code.

Please feel free to reopen the bug if you do find that the performance problems persist even with the latest versions of the driver.

Thanks,

-Carl
 

(In reply to comment #27)
> (In reply to comment #26)
> > I've done some testing with OpenSUSE 11.1 Beta5 (the KDE4 LiveCD) and
> > identified some performance issues.
> As described in comment #26, the performance problems appear to exist in
> OpenSUSE 11.1 Beta5 but not in the xf86-video-intel code which is currently a
> release candidate for the upcoming 2.6 release.
> So whatever the bug is, it appears to be fixed in the current code.
> Please feel free to reopen the bug if you do find that the performance problems
> persist even with the latest versions of the driver.
> Thanks,
> -Carl

Carl, do you think if we can point out which patch (or patches) that fixed the performance regression issue? Even some clues of how to find them, or our graphics driver in Novell's SLED11 has big problems in performance, especially for those hardware that can work very well on SLED10.

(In reply to comment #28)

> Carl, do you think if we can point out which patch (or patches) that fixed the
> performance regression issue?

If I knew, I would be glad to share them. But sadly, I don't.

> Even some clues of how to find them,

First, identify which component (or combination of components) is causing the problem. The latest stuff that's working well is the for-review branch of anholt's kernel tree, the master branch of the xf86-video-intel driver and the master branch of the xserver repository. If a single component can be identified as the culprit, then it should be a simple matter of doing a bisect to find the specific commit(s) of interest.

But I can't guarantee that there's some simple commit that can be backported. The issue could depend on large infrastructural changes in the kernel that may not be feasible to put into whatever release is of interest here.

> or our
> graphics driver in Novell's SLED11 has big problems in performance, especially
> for those hardware that can work very well on SLED10.

That's really an issue for Novell to address. We've identified that our latest code does not have this problem. Again, when our code is having problems, then we will be happy to put time into fixing them.

Thanks,

-Carl

Since the bug is still exists in Q3RC5 release and Carl will help Novell fix this bug. I reopen this bug for track.

Dan, I think you have gotten SLED11-Beta6, please have a try for this.
Just now, I have running on x86_64 of SLED11-beta6 with the command Carl provided. Here are the result.
Seems better than Carl'testing(Carl uses SLED11-Beta4).
Composite manager is enabled, and Desktop Effect is disabled.
I will test EXA, ExaNoCompisite, XAA for this testing to check if there are much performance regression.

EXA results
----
aatrap1x1
1600000 trep @   0.0070 msec (143000.0/sec): Fill 1x1 aa trap

aatrap10x10
 600000 trep @   0.0145 msec ( 69200.0/sec): Fill 10x10 aa trap

aatrap2x1
1800000 trep @   0.0063 msec (160000.0/sec): Fill 2x1 aa trap

aatrap2x10
 800000 trep @   0.0157 msec ( 63700.0/sec): Fill 2x10 aa trap

aa10text
 480000 trep @   0.0299 msec ( 33500.0/sec): Char in 80-char aa line (Charter 10)

aa24text
 320000 trep @   0.0333 msec ( 30000.0/sec): Char in 30-char aa line (Charter 24)

rgb10text
 480000 trep @   0.0302 msec ( 33100.0/sec): Char in 80-char rgb line (Charter 10)

rgb24text
 320000 trep @   0.0364 msec ( 27500.0/sec): Char in 30-char rgb line (Charter 24)

scroll10
4000000 trep @   0.0044 msec (225000.0/sec): Scroll 10x10 pixels

Scroll100
 400000 trep @   0.0302 msec ( 33200.0/sec): Scroll 100x100 pixels

copywinwin10
3200000 trep @   0.0038 msec (263000.0/sec): Copy 10x10 from window to window

copywinwin100
 400000 trep @   0.0310 msec ( 32200.0/sec): Copy 100x100 from window to window

copypixwin10
2400000 trep @   0.0042 msec (236000.0/sec): Copy 10x10 from pixmap to window

copypixwin100
 320000 trep @   0.0321 msec ( 31200.0/sec): Copy 100x100 from pixmap to window

PutImage10
3200000 trep @   0.0034 msec (295000.0/sec): PutImage 10x10 square

PutImage100
 240000 trep @   0.0545 msec ( 18300.0/sec): PutImage 100x100 square

ShmPutImage10
3200000 trep @   0.0040 msec (249000.0/sec): ShmPutImage 10x10 square

ShmPutImage100
 400000 trep @   0.0313 msec ( 31900.0/sec): ShmPutImage 100x100 square

GetImage100
  24000 trep @   0.5291 msec (  1890.0/sec): GetImage 100x100 square

GetImage500
    800 trep @  12.6716 msec (    78.9/sec): GetImage 500x500 square

compwinwin10
3200000 trep @   0.0041 msec (243000.0/sec): Composite 10x10 from window to window

compwinwin100
 320000 trep @   0.0325 msec ( 30800.0/sec): Composite 100x100 from window to window

comppixwin10
2400000 trep @   0.0045 msec (222000.0/sec): Composite 10x10 from pixmap to window


comppixwin100
 320000 trep @   0.0342 msec ( 29300.0/sec): Composite 100x100 from pixmap to window

----

SLE11-Beta6

Test data of x11perf on T61 with XAA, EXA, EXANoComposite  
                             EXA        EXANoComposite          XAA
aatrap1x1               143000.0        54500.0:-61%    92700.0:-35%
GetImage100x100           1890.0        1890.0          1850.0:-2%
aatrap2x1               160000.0        49800.0:-68%    91900.0:-42%
ShmPutImage100x100       31900.0        31600.0         27400.0:-14%
aatrap2x10               27500.0        35200.0:28%     83600.0:204%
ShmPutImage10x10        249000.0        247000.0        455000.0:82%
Scroll10x10             225000.0        219000.0:-2%    263000.0:16%
Scroll100x100            31200.0        31000.0         28300.0:-9%
aatrap10x10              69200.0        44500.0:-35%    67400.0:-2%
PutImage100x100          18300.0        18100.0:-1%     16600.0:-9%
GetImage500x500          29300.0        29400.0         27500.0:-6%
PutImage10x10           295000.0        283000.0:-4%    378000.0:28%

Based on the results, we have found EXA has excellent performance. Please take a try on SLE11-Beta6 to see  if there are some improvement on graphics performance.

Thanks
I don't do any change on graphics drivers. Just disable Desktop Effect, Composite Manager is enabled based on xdpyinfo output.

not blocking 18858 (2.6 Q4 release), since the upstream code doesn't have problem.

There are some interesting benchmarks available at http://www.phoronix.com/scan.php?page=article&item=intel_graphics_q408&num=1 on the latest Intel video performance.  This seems to mirror what I've been seeing where some benchmarks are significantly faster while others are significantly slower.  Performance issues notwithstanding, does anyone else see the graphics corruption issues with java apps?  It only seems to occur in certain applications but even 2d simple java apps like Lux (http://sillysoft.net/lux/) are unusable with EXA enabled.

(In reply to comment #33)
> Performance issues notwithstanding, does anyone else see the graphics
> corruption issues with java apps?  It only seems to occur in certain
> applications but even 2d simple java apps like Lux (http://sillysoft.net/lux/)
> are unusable with EXA enabled.

I do witness those java applications issues as well on the Novell GroupWise client. I will try http://sillysoft.net/lux/ as well.

(In reply to comment #33)
> Performance issues notwithstanding, does anyone else see the graphics
> corruption issues with java apps?  It only seems to occur in certain
> applications but even 2d simple java apps like Lux (http://sillysoft.net/lux/)
> are unusable with EXA enabled.

Hi Dan,

While I do genuinely appreciate you reporting new issues, can you please do so in a new bug report? If we discuss multiple issues under a single bug report then actions like "closing bug as fixed" quickly become meaningless.

Thanks,

-Carl
 

Sorry for that, I certainly understand wanting to keep bug reports as focused as possible and the graphics corruption isn't a performance issue.  I've opened bug # 19352 to track the display corruption of java apps.

Hi, Carl
For the performance in Q3 release, do you have some idea about that? Where we can start to investigate what the problem is?

(In reply to comment #37)
> Hi, Carl
> For the performance in Q3 release, do you have some idea about that? Where we
> can start to investigate what the problem is?

I'm not sure what problem you're referring to here.

In general, for any issue, you should be able to follow the steps I described in comment #29.

So what's the issue of interest here? And where do you stand with respect to the steps I suggested in comment #29?

-Carl

(In reply to comment #38)
> (In reply to comment #37)
> > Hi, Carl
> > For the performance in Q3 release, do you have some idea about that? Where we
> > can start to investigate what the problem is?
> 
> I'm not sure what problem you're referring to here.
The performance of Q3 release is not good. 
> 
> In general, for any issue, you should be able to follow the steps I described
> in comment #29.
> 
> So what's the issue of interest here? And where do you stand with respect to
> the steps I suggested in comment #29?
Just as you said, kernel have been made a big change. I ever tried to backport the kernel (GEM), however it is not acceptable by Novel, because it has touched other modules except drm, agp more deeply. 

Now we can only check on 2d, 3d for verification.
 
> 
> -Carl
> 

Well... I'm not sure if I'm writing this in the correct place (hope I am), but I'm able to see this bug on Ubuntu Jaunty Beta 2 (almost beta 3 actually) with following package versions:

libglu1-mesa                               7.2+git20081209.a0d5c3cf-0ubuntu4
xserver-xorg-core                          2:1.5.99.3-0ubuntu4
xserver-xorg-video-intel                   2:2.5.1-1ubuntu7

00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)


stetzen@stetzen-laptop:~$ uname -a
Linux stetzen-laptop 2.6.28-4-generic #9-Ubuntu SMP Tue Jan 6 19:34:01 UTC 2009 i686 GNU/Linux


I'm attaching Xorg.0.log, hope It'll help you somehow.

Created attachment 21804 [details]
Xorg.0.log for Ubuntu Jaunty with 2.6.28 kernel xserver 1.6 beta and intel driver 2.5

I'm adding a me too message here.  I'm on openSUSE 11.1 on thinkpad x61s with GM965 and EXA is very slow.  I'll attach lspci -nn output and video capture of window/workspace switching and stuff on EXA and XAA.

Created attachment 22029 [details]
lspci -nn output on tp x61s

Can't attach videos here directly due to size limitations.

Video with EXA: http://htj.dyndns.org/export/exa.avi
Video with XAA: http://htj.dyndns.org/export/xaa.avi

The videos are captured with a cheap webcam so the quality isn't stellar but is sufficient to demonstrate the performance regression with EXA.  Feeling slow or fast sure is subjective but the difference is large enough and that level of slowness would be quite annoying for most people.

Thanks.

Just a small note from "yet another user" -- Dell E6500, for me EXA is way faster than XAA, according to:
        x11perf -copypixwin500
In EXA I get ~1920 (frames?) per sec, when for XAA 200-300. However, from user POV I can only say, what is already been said -- (KDE3.5.10) moving windows, window-switching, scrolling, watching movies is very slow.

I will be out of the office until March 2nd but will respond to your email as quickly as possible when I return.
Thank you for your patience,
Dan

I'm closing this bug because, as described in comments #26 and #27, analysis showed that the problems existed in the OpenSuSE Beta but not in the latest versions of the driver, (potentially including kernel components).

If there are separate issues discussed here that people are still interested in, I'm not trying to ignore them. But we need separate bug reports for those so that we can track them better. So please feel free to open new bugs for any outstanding issues.

Thanks for your understanding,

-Carl