[Pixman] [PATCH 0/5] PRNG upgrade for pixman tests

Siarhei Siamashka siarhei.siamashka at gmail.com
Sat Dec 1 16:47:18 PST 2012


On Thu, 29 Nov 2012 13:19:11 +0100
sandmann at cs.au.dk (Søren Sandmann) wrote:

> Siarhei Siamashka <siarhei.siamashka at gmail.com> writes:
> 
> > As for the SIMD implementation, I decided to take a somewhat unusual
> > approach. Typically one uses CPU-specific intrinsics. This provides
> > support for just one hardware platform (let's say x86 SSE2), but
> > with a choice of multiple compilers (gcc, clang, icc, ...). I decided
> > to do this the other way around :) And implemented the code using
> > the GCC specific vector extensions:
> >     http://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html
> > This means that just a single compiler is supported (GCC 4.7 or newer),
> > but the code is quite conveniently optimized for multiple platforms at
> > once (x86 SSE2, ARM NEON, PPC Altivec, ...).
> 
> It might be interesting to try using these extensions within pixman
> itself as a fallback for the cases where we don't have CPU specific fast
> paths.

GCC vector extensions is still a somewhat experimental feature. In
particular it has problems with unaligned memory accesses, at least on
one platform:
    http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55454
This is not so critical for filling buffers with random data in
pixman tests, because it is easy to align memory buffers. And for
unaligned buffers, memcpy workaround is still somewhat faster than
non-simd code.

Also it is just a small subset of arithmetic operations, which are
almost guaranteed to be supported by any SIMD ISA. It happened to be
just enough for implementing a PRNG, but may be insufficient for some
advanced pixel operations.

On the other hand, it may be too early to write them off. GCC vector
extensions are nothing else but an OpenCL dialect. And OpenCL itself
may be quite interesting for speeding up high quality scaling.

-- 
Best regards,
Siarhei Siamashka


More information about the Pixman mailing list