[Pixman] Performance impact of having both NEON and ARM SIMD fast paths enabled?

[Siarhei Siamashka]

On Wednesday 10 March 2010, Koen Kooi wrote:
> Hi,
>
> I vaguely remember people saying that only one should be enabled, is
> that still true? It looks like the NEON fastpaths are a superset of the 
> ARM ones, 

We fallback directly to general implementation from NEON, bypassing ARM SIMD.
Exactly because NEON fastpaths are a superset of the ARM ones.

Disabling ARM SIMD currently only reduces library size, but does not affect
performance.

> but has anyone done any (micro)benchmarking of both on a 
> cortex-a8?

NEON is much faster in general, but there may be some special cases like doing
OVER operation with a completely transparent source (client applications can
do some really stupid things). NEON typically processes data in blocks of 8 or
more pixels at once and reads/writes all the pixel data unconditionally
without checking transparent/opaque special cases for individual pixels.
In this case ARM SIMD may be faster because it will only read source and
not touch destination at all.

On a positive side, NEON is only memory bandwidth limited for any kind of
compositing operations and computational complexity is practically irrelevant
(except when working with the data in L1/L2 caches and we are not slowed down
by memory accesses).

Another good thing about NEON is that it is easy and straightforward to add
new fast paths. It has a separate large pool of NEON registers so that loop
control and pixel processing logic are clearly separated. Older ARM processors
have to use just 14 general purpose registers for everything and it is a bit
tricky to make really optimal fast path functions.

I can provide some microbenchmarking data if you are interested.

-- 
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.freedesktop.org/archives/pixman/attachments/20100310/f4dbb4b0/attachment.pgp>