commit a1e6abb5ca89d699144d10fdc4309b3b78f2f7a9 Author: Eric Anholt <eric@anholt.net> Date: Wed Jul 15 14:15:10 2009 -0700 Use batch_start_atomic to fix batchbuffer wrapping problems with 8xx render. This patch horribly affects global 2D performance after a while. I can easily reproduce the slowdowns by using text-intensive applications (gitk, thunderbird, ...) and tab-switching really quickly between them (fully maximised). With that setup, the slow down appear in a matter of minutes. To further confirm this bug, "x11perf -aa10text" shows ~200k chars/sec on the last good commit and only ~20k chars/sec when the slow down occurs. Only restarting X temporarily solves the slow down. Distro : Gentoo unstable x86 Kernel : 2.6.31-rc2-00457-gdff33cf (no KMS) xorg-server : 1.6.2 + all patches from the nomination page libdrm : 9aed44beeac (git master as of today) xf86-video-intel : see above mesa : somewhere around 7.5, I can check if needs be Thanks
Remi, Thanks for the report. Eric, This is an 855 performance issue related to a recent commit of yours. See details above. -Carl
I have a user reporting the exact same symptoms on a 965GM. I'll try to get him to confirm the bisect I did. Thanks
(In reply to comment #2) > I have a user reporting the exact same symptoms on a 965GM. I'll try to get him > to confirm the bisect I did. False alarm, just a missing drm module. Still just my 855 for now. Thanks
With commit a1e6abb5ca89d699144d10fdc4309b3b78f2f7a9 ( Bug #22483 ) I can also see the slowdowns after a few minutes, especially with the SpeedDial Firefox extension. Tab switching becomes very slow, ~4 seconds without composition and ~1 second with Kwin composition. When the slowdowns occurs, the Xorg process uses 30-40% CPU. some "x11perf -aa10text" tests without composition: before a1e6abb5ca89d699144d10fdc4309b3b78f2f7a9 (batch_start_atomic fix): 240000 reps @ 0.0238 msec ( 42000.0/sec): Char in 80-char aa line (Charter 10) after a1e6abb5ca89d699144d10fdc4309b3b78f2f7a9: 56000 reps @ 0.0877 msec ( 11400.0/sec): Char in 80-char aa line (Charter 10) after 12c5aeca7a3db92d3522d00f5daf338d522e2176 (8xx render: Add limited support for a8 dests): 800000 reps @ 0.0069 msec (145000.0/sec): Char in 80-char aa line (Charter 10) after some minutes with 12c5aeca7a3db92d3522d00f5daf338d522e2176 everything slowdowns and when performing aa10text again it hangs as commented in the commit. Additionally With 2.7.0 RC using EXA: 1600000 reps @ 0.0037 msec (271000.0/sec): Char in 80-char aa line (Charter 10 With 2.4.1 using EXA: 1600000 reps @ 0.0056 msec (179000.0/sec): Char in 80-char aa line (Charter 10) 00:02.0 VGA compatible controller: Intel Corporation 82865G Integrated Graphics Controller (rev 02) linux: 2.6.30-10-generic xserver: 2:1.6.2+git20090724+server-1.6-branch.606f6dba-0ubuntu0sarvatt2~jaunty intel: 2:2.8.0+git20090724.9a45ace2-0ubuntu0sarvatt~jaunty libdrm: 2.4.12+git20090717.9aed44be-0ubuntu0sarvatt~jaunty mesa: 7.6.0~git20090715.3a3b83e5-0ubuntu0sarvatt~jaunty
Hi Eric, Is there anything I can do to help? Thanks
Created attachment 29074 [details] Sysprof trace of aa10text with a freshly started X-Server; >300k chars/sec.
Created attachment 29075 [details] Sysprof trace of aa10text after using the X-Server for a while; <20k chars/sec.
Kernel: 2.6.31-rc8 + everything from drm-intel-next xserver: 1.6.3.901 pixman: 0.14.0; newer releases don't make a difference libdrm: 2.4.13 x86; no KMS.
Interesting. Quite clearly we hit the fallback paths. There's no single trigger, just a period of general usage? Even more weird is that the commit pointed to by the bisection looks sane. If you can add: Section "Device" Option "FallbackDebug" "true" EndSection and upload the resulting /var/log/Xorg.0.log when you hit the slowdown. Hopefully that'll be instructive as to why we suddenly start hitting the fallback paths.
Created attachment 29078 [details] Xorg fallback debug log This log captures a KDE 4.3 session, where I opened a Firefox 3.5 window with http://www.heise.de/newsticker/ and used full page zoom (deactivated "Zoom text only"). When doing so, everything became just slow. "x11perf -aa10text" showed a mere 10k/sec. Scrolling in Firefox was just a pain. Closing the firefox window made the slowness go away. The backtrace at the end is another story and most probably not related. :-) Got the idea from comment #1 in bug #20977, which might be related in some way, so i945 might be affected as well.
After futher reflection, the symptoms of this bug report should indeed be fixed by: commit 9c1bf6d01ca307b7a9b91e181ad7f341862e5e1c Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Sep 4 23:31:44 2009 +0100 i830: do not use stale mask transform Not only were incorrectly falling back if we had non-affine transformations, but we made the decision based on a stale transformation matrix. So does anybody still see the spontaneous slowdowns with the current tip of the xorg driver?
Still testing it out but I haven't seen slow downs so far. If I don't report back within a day or two, consider this bug fixed. Thanks for the patches :)
I guess we all agree that this one is fixed. :-)
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.