| Summary: | [855GM regression] batch_start_atomic horribly breaks performance after a while | ||
|---|---|---|---|
| Product: | xorg | Reporter: | Rémi Cardona <remi> |
| Component: | Driver/intel | Assignee: | Chris Wilson <chris> |
| Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> |
| Severity: | normal | ||
| Priority: | high | CC: | maxi |
| Version: | unspecified | Keywords: | regression |
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | |||
|
Description
Rémi Cardona
2009-07-21 12:48:32 UTC
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.