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).
>> Both Konsole 3.5.9 (without a background pixmap) and a recent xterm are
>> equally sluggish;
>
> xterm uses core fonts by default, did you configure it differently?
I just used -fa/-fs to force client-side fonts.
>> X: fbFetch_a1 10.92
>> dixLookupPrivate 7.04
>> fbStore_a1 3.70
>> mmxCombineAddU 3.06
>> pixman_image_composite 2.58
>
> [...]
>
>> 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().
>
> No, at least with EXA, fb*_a1 can't access video RAM directly, as the
> EXA core currently never migrates pixmaps of bpp < 8 to video RAM.
This was a profile with XAA, not EXA. Here's a more comprehensive set of
results (using xterm at all times, 'non-AA' forced by using my preferred
terminal font, the bitmap font Neep Alt), started and stopped by hand so
it's all quite crude, roughly 60s per benchmark run (so I can't explain
sysprof's saying that some runs spent 90s in X: on a single core that
seems quite unlikely):
XAA, 16, AA: fbCompositeSolidMask_nx8888x0565Cmmx 59.25 (time in X, 90.12)
XAA, 24, AA: fbCompositeSolidMask_nx8888x8888Cmmx 57.12 (time in X, 85.03)
EXA, 16, AA: dixLookupPrivate 23.17
visually much faster than XAA, occasionally degrades to
XAA speed
EXA, 24, AA: dixLookupPrivate 26.83
XAA, 16, non-AA: fbFetch_a1 12.43 %time in X, 79.96)
XAA, 24, non-AA: fbFetch_a1 14.51 (time in X, 87.60) (v. slow in konsole,
very slightly faster-seeming in xterm but profile results
identical so this is just an artifact of differing repaint
strategies)
EXA, 16, non-AA: fbFetch_r5g6b5 53.40, fbFetch_a1 5.75 (time in X, 95.88)
horrendously, impossibly slow, >10s for a single screen repaint
EXA, 24, non-AA: fbFetch_a1 12.40 (89.34s in X)
much better than the abominable depth 16 results, back to
XAA speed
XAA, 16, core: cat, bash, xterm; CPU load nearly nil; screen a blur far too
fast to read
highest consumer in X, at <1s, DrawTETextScanlineWidth7()
XAA, 24, core: cat, bash, xterm; CPU load nearly nil; screen a blur far
too fast to read; highest consumer in X, at <1s,
DrawTETextScanlineWidth7()
EXA, 16, core: pixman_fill_mmx 22.17, fbGlyph16 15.83, CPU still pegged by X,
in sharp contrast to non-EXA; (time in X, 62.58)
EXA, 24, core: pixman_fill_mmx 37.51, fbGlyph32 13.63 (time in X, 69.48)
better than anything else bar core XAA
In general, core fonts much faster than client-side fonts, 24-bit as
fast or faster than 16-bit (this has changed in the about eight years
since I paid any attention to it last, and DRI no longer stops working
in 24-bit mode: maybe I'll switch), XAA faster than EXA with the single
exception of anti-aliased fonts, which I don't use in terminals and
text editors because I like my text small enough that antialiasing is
uglier than not.
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 :( isn't X supposed to
use *less* CPU time than the apps that call on it? :(((
> 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.
The benchmarks show that this would indeed speed things up. It would
also eliminate every font I use day-to-day and give me piercing
headaches. No thanks, let's find another way. :)
>> (++) RADEON(0): Depth 16, (--) framebuffer bpp 16
>> (II) RADEON(0): Pixel depth = 16 bits stored in 2 bytes (16 bpp
>> pixmaps)
>
> Is it any better in depth 24, or even worse?
(See above.)
Better under EXA: sometimes better, sometimes worse under XAA (better
for antialiased fonts only, all others worse, or too fast to tell in
the case of core fonts).
_______________________________________________
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
