On Thu, 29 Nov 2012 13:19:11 +0100 sandm...@cs.au.dk (Søren Sandmann) wrote:
> Siarhei Siamashka <siarhei.siamas...@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 _______________________________________________ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman