Comparing EXA to NoAccel

[Carl Worth]

> I'll follow up with more specific comments analyzing some specific
> results here. And I encourage others to do the same.

One of the obvious things to look at first is where is EXA actually
slower than the NoAccel case. You can manually scan through the
previous results to find instances, but it's much easier to run
cairo-perf-diff-files on just the two files of interest.

Which reminds me I didn't provide those files before, so here they are
now:

	http://people.freedesktop.org/~cworth/cairo-exa-vs-xaa/

Each of the .perf files are the results I got from running cairo-perf,
and the .txt files are generated with cairo-perf-diff-files. For
example, I just did:

	./cairo-perf-diff-files noaccel.perf exa.perf >	exa-vs-noaccel.txt

to make that file, and I'll include some highlights (and lowlights) here:

old: noaccel
new: exa
Speedups
========
 xlib-rgb       paint_solid_rgba_over-512  386.65 ->  5.92: 72.76x speedup
███████████████████████████████████▉
 xlib-rgb     paint_similar_rgba_over-512  454.93 -> 12.84: 35.90x speedup
█████████████████▌
 xlib-rgb       paint_image_rgba_over-512  462.79 -> 22.28: 20.72x speedup
█████████▉
 xlib-rgb      text_solid_rgba_source-256  235.04 -> 14.26: 17.29x speedup
████████▏
 xlib-rgb       text_solid_rgb_source-256  235.09 -> 14.53: 17.00x speedup
████████
 xlib-rgb     text_similar_rgb_source-128   58.50 ->  3.76: 16.49x speedup
███████▊
 xlib-rgb    text_similar_rgba_source-128   58.47 ->  3.77: 16.44x speedup
... (many similar speedups here)

So that shows that some things are definitely working well. The 36x
speedup when rendering an ARGB xlib surface over an RGB xlib surface
looks quite nice in fact. That seems a very useful operation to have
running many times faster than the noaccel case.

But then there's some not so nice stuff as well:

Slowdowns
=========
 xlib-rgba                 rectangles-512    5.70 ->  79.14: 14.01x slowdown
██████▌
 xlib-rgba  paint_similar_rgba_source-256    0.15 ->   1.61: 11.09x slowdown
█████
 xlib-rgba    paint_solid_rgba_source-256    0.09 ->   0.77:  8.57x slowdown
███▊
 xlib-rgba     paint_solid_rgb_source-256    0.09 ->   0.77:  8.54x slowdown
███▊
 xlib-rgba       paint_solid_rgb_over-256    0.09 ->   0.77:  8.53x slowdown
███▊
 xlib-rgba        fill_solid_rgb_over-256    2.06 ->   8.16:  3.99x slowdown
█▌

The 14x slowdown on the rectangles case is a huge problem. That's by
far the most frequently drawn object in most 2D user interfaces.

The various paint slowdowns are a problem as well. When doing paint
with an ARGB similar surface and the Source operator to another ARGB
surface, (the second example above with the 11x slowdown), we're
really just talking about a straight copy of bits. So something stupid
must certainly be happening somewhere.

The last couple results above show an RGB surface Over an ARGB
surface, so there's slightly more than a copy happening, (the
destination alpha needs to be set to 1.0 for each pixel), but somehow
EXA still manages to got 8.5 times slower than the NoAccel case.

There are many other similar slowdowns, but here's one I'll point out
from later on in the list:

 xlib-rgb         fill_solid_rgb_over-256    3.71 ->   7.98:  2.16x slowdown
▋

Here, the Over operation should be exactly just a copy since the
source and the destination have no alpha. But EXA is still 2x slower
than NoAccel.

One potential upside to this is that there may be just one bug that is
causing all of the slowdowns I see here. Anyone have a guess at what
that might be and how easy the fix might be?

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20070425/c86197f5/attachment.pgp>