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

Nix nix at esperi.org.uk
Sun Feb 1 04:54:39 PST 2009


On 31 Jan 2009, Michel Dänzer outgrape:
> On Fri, 2009-01-30 at 21:59 +0000, Nix wrote:
>> On 30 Jan 2009, Michel Dänzer stated:
>> >Trying current xf86-video-ati Git might be good, but my main suggestion
>> >would be to try xserver Git server-1.6-branch with EXA.
>> 
>> OK. Do I need to upgrade Mesa or anything related at the same time? 
>> (I'm currently on libdrm 2.4.1, Mesa a few commits past 7.2.0).
>
> I think that should be fine; if anything 3D related breaks though, you
> can always try upgrading to Mesa 7.3. :)

I'll give it a try.

>> This was a profile with XAA, not EXA. Here's a more comprehensive set of
>> results [...]
>
> Ah, so some of those hotspots might indeed be direct VRAM access. With
> EXA, does it help if you run a compositing manager, even just xcompmgr
> -a?

I'll give that a try as well :)

>> I must say, looking at these crude benchmark results I'm wondering if
>> this client-side font thing wasn't an appealing diversion. Yes, they're
>> pretty, and more flexible than core fonts: but all of a sudden simply
>> simply redrawing the screen has become so CPU-intensive that a screen
>> scroller can peg the CPU without any real effort :(
>
> The EXA glyph cache introduced in xserver 1.6 greatly improves rendering
> of client side fonts - some people have reported in excess of 5 million
> glyphs/s on beefy Radeons. Unfortunately there are still a couple of
> cases it doesn't support well in xserver 1.6, hopefully we can fix those
> for 1.7.

Excellent! :)

>> > To avoid a1 pictures, you could try using anti-aliasing everywhere, i.e.
>> > don't choose any bitmap fonts and don't disable anti-aliasing for small
>> > font sizes.
[..]
> I think a big part of the motivation for client side fonts was indeed
> anti-aliasing, so if you don't want AA and core fonts are faster for
> you, just use core fonts?

That's Not really practical, because they involve different APIs,
different font matching mechanisms, and so forth: they aren't really
interchangeable. I don't think an attempt to convince the KDE hackers to
allow konsole to use core fonts would go very far, not least because
core fonts are generally seen as obsolescent (`fix the slow X server',
they'd chorus). And I'm not aware of any decent tabbing terminal
emulators that use core fonts: certainly none that also allow DCOP
automation, which I use all the time...

Jim's comments here are, as ever, apposite :)



More information about the xorg mailing list