[cairo] pixman: New ARM NEON optimizations

[Siarhei Siamashka]

On Tuesday 16 February 2010, Koen Kooi wrote:
> On 16-02-10 16:56, Siarhei Siamashka wrote:
> > On Thursday 05 November 2009, Chris Wilson wrote:
> >> Before going too far along the performance, make sure you are also
> >> checking with Søren's work in reducing overheads.
> >>
> >> Also I'm very interested in seeing what the profiles look like for
> >> pixman and cairo on ARM. Just knowledge of the behaviour of your target
> >> applications would be useful when thinking about how to tune cairo.
> >
> > Here is a result of running a standard set of cairo-perf-trace tests on
> > 600MHz ARM Cortex-A8 with 128MB RAM (beagleboard B7):
> > http://people.freedesktop.org/~siamashka/files/20100216/pixman-0.17.6/
>
> Thanks for putting that together! Would it be possible to mark fastpaths
> with a different colour/border? That would picking slowpaths from the
> picture a lot easier :)

It's just a standard callgraph generated by this script:
http://code.google.com/p/jrfonseca/wiki/Gprof2Dot

Tweaking it and additionally highlighting some important functions
is probably possible. But the people who are familiar with the code,
can see performance problems even without such highlighting :)

On the other hand, end users may have some use cases which run
slow, but they don't have any easy way to check whether pixman has
all the needed optimizations for it already or not. Or whether there could
be some other performance bottleneck on the boundary between different
components/libraries or anything else.

When looking into oprofile log, any functions with 'composite' part in their
names and without 'neon' suffix or prefix are potential candidates for
optimizations. Also the presence of any 'combine_*' or 'delegate_*' functions
shows that something is not very optimal (unless the source image is scaled,
which is a bit special).

We also experimented a bit with the pixman patches intended for collecting
fast path functions usage statistics, but they were not particularly
useful in my opinion.

-- 
Best regards,
Siarhei Siamashka
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.cairographics.org/archives/cairo/attachments/20100216/e71aeb5c/attachment.pgp