Author: Eric Anholt <email@example.com>
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 for the report.
This is an 855 performance issue related to a recent commit of yours. See details above.
I have a user reporting the exact same symptoms on a 965GM. I'll try to get him to confirm the bisect I did.
(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.
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)
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.
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)
Is there anything I can do to help?
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
pixman: 0.14.0; newer releases don't make a difference
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:
Option "FallbackDebug" "true"
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:
Author: Chris Wilson <firstname.lastname@example.org>
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
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. :-)