[Pixman] [PATCH 0/3] ARM NEON optimizations for better results in cairo-perf benchmarks

Siarhei Siamashka siarhei.siamashka at gmail.com
Thu Feb 25 06:43:11 PST 2010


On Wednesday 24 February 2010, Soeren Sandmann wrote:
> Siarhei Siamashka <siarhei.siamashka at gmail.com> writes:
> > The following patches add some new 32bpp ARM NEON optimized fast paths
> > for the operations which are heavily used in the standard cairo-perf
> > benchmarks. Profiling statistics has been posted earlier:
> > http://people.freedesktop.org/~siamashka/files/20100216/pixman-0.17.6
>
> It looks like most of these could be enabled in the ABGR case as
> well. The pixbuf fast path also looks like it could be used as in the
> [rpixbuf, a8b8g8r8] case.

Yes, you are right. I always keep forgetting about ABGR formats :)

My only concern is about adding extra entries in the fast path tables for the
operations which are likely to be never used. They are going to just decrease
performance somewhat in the case when there is no fast path available and we
fall back to the general case. More is not always better.

For example, in the following trace the source of slowness was the use of
general path 'fast_composite_over_n_8888_8888_ca' function. But going through
all the fast path entries before reaching this fallback introduced additional
overhead (can be seen as a high CPU usage in '_pixman_run_fast_path'):
http://people.freedesktop.org/~siamashka/files/20100216/pixman-0.17.6/image-firefox-talos-gfx.png

But I understand that fast path cache (which is coming to pixman eventually?)
is going to improve the performance in such cases and this should basically
become a non-issue.

I also wonder if it makes sense to treat ARGB format as a canonical case, and
do equivalent image format substitutions at the operators optimization stage?

-- 
Best regards,
Siarhei Siamashka


More information about the Pixman mailing list