Re: Some x11perf numbers for O2

[Michael <macallan%netbsd.org@localhost>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

On Mar 20, 2009, at 12:35 PM, Andrew Randrianasulu wrote:

> This is from NedBSD-current/sgimips (almost current). 5.99.7 and  
> native Xorg, hammered into 5.0_beta system. CPU - r5k 180Mhz, 256Mb  
> main memory.
>
> -------
> sgio2$ x11perf -shmput500
> x11perf - X11 performance program, version 1.5
> The Xorg Foundation server version 10402000 on :0.0
> from sgio2
> Fri Mar 20 12:54:05 2009
>
> Sync time adjustment is 0.4393 msecs.
>
> shmget: Cannot allocate memory
>
> sgio2$
>
> sgio2$ x11perf -putimage500
> x11perf - X11 performance program, version 1.5
> The Xorg Foundation server version 10402000 on :0.0
> from sgio2
> Fri Mar 20 12:54:35 2009
>
> Sync time adjustment is 0.4575 msecs.
>
>     28 reps @ 188.9957 msec (     5.3/sec): PutImage 500x500 square
>     28 reps @ 192.4934 msec (     5.2/sec): PutImage 500x500 square
>     28 reps @ 189.3289 msec (     5.3/sec): PutImage 500x500 square
>     28 reps @ 193.2103 msec (     5.2/sec): PutImage 500x500 square
>     28 reps @ 189.3748 msec (     5.3/sec): PutImage 500x500 square
>    140 trep @ 190.6806 msec (     5.2/sec): PutImage 500x500 square
>
> sgio2$

I wonder if we can accelerate this by missing with one of the linear  
TLBs or if the overhead of ioctl(), uvm_extract etc. kills the speedup  
again

> sgio2$ x11perf -aa10text
> x11perf - X11 performance program, version 1.5
> The Xorg Foundation server version 10402000 on :0.0
> from sgio2
> Fri Mar 20 12:55:58 2009
>
> Sync time adjustment is 0.4447 msecs.
>
> 1600000 reps @   0.0053 msec (190000.0/sec): Char in 80-char aa line  
> (Charter 10)
> 1600000 reps @   0.0055 msec (183000.0/sec): Char in 80-char aa line  
> (Charter 10)
> 1600000 reps @   0.0055 msec (183000.0/sec): Char in 80-char aa line  
> (Charter 10)
> 1600000 reps @   0.0055 msec (182000.0/sec): Char in 80-char aa line  
> (Charter 10)
> 1600000 reps @   0.0056 msec (180000.0/sec): Char in 80-char aa line  
> (Charter 10)
> 8000000 trep @   0.0055 msec (183000.0/sec): Char in 80-char aa line  
> (Charter 10)
>
> sgio2$
>
> (damn fast!)

That's pretty quick indeed, I've seen machines that are slower than  
that when colour-expanding monochrome font images.

> sgio2$ x11perf -aa24text
> x11perf - X11 performance program, version 1.5
> The Xorg Foundation server version 10402000 on :0.0
> from sgio2
> Fri Mar 20 12:57:27 2009
>
> Sync time adjustment is 0.4467 msecs.
>
> 640000 reps @   0.0134 msec ( 74800.0/sec): Char in 30-char aa line  
> (Charter 24)
> 640000 reps @   0.0136 msec ( 73700.0/sec): Char in 30-char aa line  
> (Charter 24)
> 640000 reps @   0.0140 msec ( 71600.0/sec): Char in 30-char aa line  
> (Charter 24)
> 640000 reps @   0.0140 msec ( 71500.0/sec): Char in 30-char aa line  
> (Charter 24)
> 640000 reps @   0.0139 msec ( 72100.0/sec): Char in 30-char aa line  
> (Charter 24)
> 3200000 trep @   0.0138 msec ( 72700.0/sec): Char in 30-char aa line  
> (Charter 24)
>
> sgio2$
>
> (very fast too)

Looks like it scales pretty much linear with character size so at  
least I'm not wasting time ;)

> sgio2$ glxgears
> 111 frames in 5.2 seconds = 21.474 FPS
> 96 frames in 5.3 seconds = 18.206 FPS
> 96 frames in 5.3 seconds = 18.183 FPS
> 96 frames in 5.2 seconds = 18.364 FPS
> 96 frames in 5.4 seconds = 17.928 FPS
> 96 frames in 5.3 seconds = 18.282 FPS
> 96 frames in 5.8 seconds = 16.594 FPS
> 96 frames in 5.2 seconds = 18.397 FPS
> 96 frames in 5.3 seconds = 18.279 FPS
> 96 frames in 5.7 seconds = 16.796 FPS
> 96 frames in 5.2 seconds = 18.504 FPS
> 96 frames in 5.7 seconds = 16.831 FPS
> X connection to :0.0 broken (explicit kill or server shutdown).
> sgio2$

That should be dominated by software rendering time.

> For comparison - "x11perf -aa10text" gives barely 9800 glyphs/sec on  
> unaccelerated fb driver in Linux. And my current x86 (950Mhz duron,  
> rv280 agp radeon card, EXA acceleration) system .....

Ouch.

> guest@slax:/$ x11perf -aa10text
> x11perf - X11 performance program, version 1.5
> The X.Org Foundation server version 10699001 on :0.0
> from slax
> Fri Mar 20 19:29:15 2009
>
> Sync time adjustment is 0.2050 msecs.
>
> 320000 reps @   0.0163 msec ( 61300.0/sec): Char in 80-char aa line  
> (Charter 10)
> 320000 reps @   0.0181 msec ( 55300.0/sec): Char in 80-char aa line  
> (Charter 10)
> 320000 reps @   0.0182 msec ( 54900.0/sec): Char in 80-char aa line  
> (Charter 10)
> 320000 reps @   0.0169 msec ( 59200.0/sec): Char in 80-char aa line  
> (Charter 10)
> 320000 reps @   0.0169 msec ( 59300.0/sec): Char in 80-char aa line  
> (Charter 10)
> 1600000 trep @   0.0173 msec ( 57900.0/sec): Char in 80-char aa line  
> (Charter 10)

That's dog slow.

For comparison, an Ultra 60 with an ffb2+ board manages about 1110000/ 
sec here, and about 368000/sec with -aa24text ( not a typo, the number  
of trailing zeroes is exactly right - the Creator3D manages about 1.1  
million anti-aliased characters per second in the -aa10text test ).  
You might get better results with XAA instead of EXA.

> So, anti-aliased text very very FAST on crime driver!

Well, as far as crime is concerned applying an 8bit alpha map and a  
static colour ( as in, drawing anti-aliased text ) is just a regular  
blitter operation. We don't need to use the texture unit so we can wet  
away with a lot less setup, no need to deal with texture size  
restrictions and whatnot. It's about the same amount of work we'd do  
for colour expansion. It's similar with the creator and there we can  
just write the alpha-map into the framebuffer and let the 3dram's  
built-in ALUs do the actual work.

Just for laughs - care to run the same test on IRIX? ;)

have fun
Michael


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQEVAwUBScWTX8pnzkX8Yg2nAQKenQf8C4j0vde6Z77Bln9hcUnr3PHgHrVUDA8U
POfbWWXo8n8zEZaAgVllxzdAOLhsz339E5WF4SQjd3r9q6gJwkcdyszU/2jXoDBR
sGHzcMlrl+VpcO9Ousgnufrpz/sEilfdpx9+pv4AIR7TmwbxpUzh44o25wC2FNjV
zrp9Vm5s3+D0/0yDscKqG49yKAhzurLhqZb2IYNMqQ4f4EjKYTuZkaxIsCpyG7I7
9186zK3Q9GjTyLEIG9xonx6CyCk1l2CC1eknRDrYkIeyK0m2aZS/BjFI/wQCsQpy
Og8IYzTypuiY+DjU+GdkhdQz721hYtl5421WrUfncKPxKHf6/dyaHA==
=U+u4
-----END PGP SIGNATURE-----