Comparing EXA to NoAccel
cworth at cworth.org
Wed Apr 25 12:38:56 PDT 2007
> 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
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:
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:
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
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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the xorg