[Pixman] [PATCH 7/7] utils.c: Increase acceptable deviation to 0.0064 in pixel_checker_t

[Søren Sandmann]

Ben Avison <bavison at riscosopen.org> writes:

> Since we're discussing bit-exactness, I have a related question. One
> nice group of instructions in ARMv6 are capable of doing things like
>
>   a += (b * c) + (d * e)
>
> in a single cycle, where b, c, d and e are 16-bit quantities. This is
> potentially useful for certain types of compositing - except that the
> way rounding is currently done, ((t + (t >> 8)) >> 8) is assumed to be
> applied after every multiply. If I do one of those fancy dual-multiply
> instructions and then round the result, it will be technically more
> accurate because the intermediate result was effectively held in 16-bit
> precision, yet it won't match the exact bit pattern tested for by some
> of the "make check" tests.

Yes, this is a large part of why I would like to change the test suite
to be based on tolerances rather than bit patterns.

> If the plan is to allow greater deviations, how can this be reconciled
> with the tests that require bitwise exact results?

As Siarhei mentioned, bitexact testing may still be useful in some
cases, but ideally, I'd like to do the following:

    - Add a floating point implementation of all pixman operations

    - Change the test suite so that it verifies that the output is close
      enough to the floating point implementation, rather than verifying
      that it matches a particular bit pattern

The benefits include more flexibility in implementation allowing things
like your single-cycle multiplication or q15 instructions or whatever,
but also makes it easier to test more aspects of pixman such as
gradients or alpha maps and makes the test suite useful for verifying
hardware accelerated X drivers.

Unfortunately, if we were to do that today, a rather large deviation of
0.0064 would have to be considered acceptable, so I'm looking for ways
to make the existing code more accurate. One thing that would help would
be to make downconversions do rounding instead of bitshifting, that is,
to convert from 8 to 6 bits, do

      v6 = floor ((v8 / 255.0) * 63.0 + 0.5)

but of course implemented with integer arithmetic:

      v6 = ((253 * v8 + 512) >> 10).

One question is what would be the performance impact of doing that on
ARMv6 rather than the current:

      v6 = v8 >> 2

The main issue I think is the pure conversion routines such as
src_8888_0565 since for something like OVER, the conversions can be
absorbed into the operation. For example over_8888_0565:

      DIV_255 (s8 * 63.0 + (255 - a8) * d6)


Søren