client-side font rendering very very slow in X.org xserver 1.5.3 w/r200: massive fetches from VRAM, why?

[Alex Deucher]

On Thu, Jan 29, 2009 at 4:16 PM, Nix <nix at 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.