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) or having the Xserver crash during resume with Xaa (https://bugzilla.novell.com/show_bug.cgi?id=439214). I have a Lenovo T61 with an Intel 965 GM card that can either suspend properly but have lousy performance (EXA) or good window drawing but not be able to resume without killing X (XAA). Since EXA appears to be the way going forward I would think the best course of action is fixing the Window drawing performance problems of EXA. With EXA enabled it feels like I'm on a slow terminal server and WINE applications in particular take forever to render. Just let me know what information I can provide.
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
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.