On Thu, Jan 29, 2009 at 4:16 PM, Nix <n...@esperi.org.uk> wrote: > I'm posting this here rather than reporting this on bz mainly because > something very similar has been reported on this list by at least one > other person in the past few months[1]: at the time, the assumption was > that this was Intel-card- related. It doesn't seem to be, because I see > it too, with a Radeon 9250 using AGP, xf86-drivers-ati > 902eaf768142c6c7dcc487e10775027b84cd1f9a, and pixman > 95f2af9584f8f4327ddf6d6948dee17ab48ad8b3. (I can upgrade to head if need > be: this just happens to be what was head when I upgraded. I can do > profile runs and the like on demand, as well.) > > [1] in <http://lists.freedesktop.org/archives/xorg/2008-December/041503.html> > > > I'm using an LCD at native res, 1680x1050. I'm *not* using a compositing > manager. Both XAA and EXA are equally slow. > > > The problem appears to be attributable to client-side fonts: using core > fonts, scrolling text flashes past far too fast to see, even at this > resolution. Using client-side fonts with no background pixmap, it takes > about a second to scroll text up the screen and out of sight (assuming > that the screen is full of text and that the scrolling is such that the > content changes, so repainting is required). Using a background pixmap > in Konsole is even slower, with scrolling up consisting of waves of > visible repainting proceeding down the screen from the top. While > scrolling, the X server pegs the (Athlon IV single-core) CPU: if the CPU > is loaded by other things, scrolling is even slower, sometimes taking > half a minute or more to scroll text as far as the top of the screen (in > a dozen or so whole-screen repaint waves: I do not claim that konsole > 3.x is particularly efficient at scrolling). > > Both Konsole 3.5.9 (without a background pixmap) and a recent xterm are > equally sluggish; gnome-terminal appears to work around the sluggishness > by virtue of repainting only about once a second, which is hardly ideal > (but this may be a configuration error: I hardly ever use > gnome-terminal.) > > You might wish to blame Konsole here, but with xserver 1.4.2 and > xf86-video-ati 6.9.0, Konsole with and without a background pixmap was > equally fast, and did not peg the CPU. If the Konsole window is hidden, > CPU consumption plunges back to normal levels, with X's consumption a > few percent at most. >
Are you using the same version of kde on both systems? IIRC kde 4 switched to using a1 surfaces for font rendering which isn't currently accelerated by EXA. Notice the _a1 fetch below. Alex > Jamie Lokier suggested (in a still-subscribers-only LWN post's comment > thread) that perhaps the problem was massive reads from video memory > because there is no shadow fb. A sysprof run agrees with this: in an 80s > run, X uses 67s and konsole 11s: the top time users are: > > X: fbFetch_a1 10.92 > dixLookupPrivate 7.04 > fbStore_a1 3.70 > mmxCombineAddU 3.06 > pixman_image_composite 2.58 > > konsole: memmove 5.37 > [everything else far subsecond] > > (alas, sysprof returns [?] as the callers for all of these. I have no > clue why: it only appears unwilling to provide caller info for the X > server. Perhaps it has something to do with dlopen()...) > > So it looks like we *are* doing huge numbers of fetches from VRAM, > judging by the massive time spent in calls upon pixman's fbFetch(). The > question is, why? And why's this only started happening in 1.5.x? Is > it a configuration error, as Jamie suggested? I've got 128Mb of VRAM, > which should be heaps for this, but seemingly we're thrashing between > VRAM and main memory all the time. _______________________________________________ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg