[Pixman] [PATCH] sse2: Using MMX and SSE 4.1

[Siarhei Siamashka]

On Fri, Jun 15, 2012 at 10:51 PM, Søren Sandmann <sandmann at cs.au.dk> wrote:
> Matt Turner <mattst88 at gmail.com> writes:
>> Also, are we planning to change the bilinear scaling algorithm for
>> 0.28 so that we can use pmaddubsw?
>
> I wouldn't object to a patch that dropped precision to 7 bits for all
> bilinear code, but it would require changes at least to the general
> code, the fast path code, the NEON code and the SSE2 code.

This is really a trivial change. The only difficulty is to enable it
and test on all the supported platforms simultaneously. Using qemu and
--enable-static-testprogs option allows to run the basic tests even
not having all the hardware. Though MIPS DSP ASE support is only being
added to qemu at the moment:
    http://lists.gnu.org/archive/html/qemu-devel/2012-03/msg04990.html

> An alternative idea is instead of changing the algorithm across the
> board, we could stop requiring bit exact results. The main piece of work
> here is to change the test suite so that it will accept pixels up to
> some maximum relative error. There is already some support for this: the
> 'composite' test is using the 'pixel_checker_t" to do compare the pixman
> output with perfect pixels computed in double precision.
>
> This latter idea is ultimately more useful because it will allow much
> more flexibility in the kinds of SIMD instruction sets we can support.

This is also a very useful test, but it effectively requires to have
an alternative double precision implementation for all the pixman
functionality to be verified. For bilinear scaling it means that at
least various types of repeats need to be handled, etc. And this
sounds like a lot of work.

There are also some alternative variants. For example, allow a custom
prefix for public symbols in pixman (so that several pixman instances
can be loaded into test application at the same time). Or even update
the existing pixman tests to add xlib support and compare the locally
rendered results with xrender. The latter seems particularly useful,
because it could be also used for xrender implementation validation in
various hardware accelerated drivers (and complement/retire
rendercheck).

-- 
Best regards,
Siarhei Siamashka