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

[Siarhei Siamashka]

On Wed, 13 Feb 2013 01:08:20 +0100
sandmann at cs.au.dk (Søren Sandmann) wrote:

> 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

This sounds more like a long term (or mid term) plan. The short term
plan might be just something like this:

  - Add some useful optimization which does not pass the current
    bit-exactness tests

  - Add a special build time option for pixman, which would make it skip
    the failing bit-exactness tests and enable this new optimization

  - Keep working on improving the coverage for the tolerance based tests

So in the short run the people who are really interested in some
important non-bitexact optimizations may be building pixman in the
configuration with these non-bitexact optimizations enabled and
somewhat relaxed test coverage.

In the long run the coverage for the tolerance based tests will
hopefully catch up.

Also if, for example, all the implementations for over_8888_0565 fast
path were to be changed at the same time to do compositing directly
with r5g6b5 destination without intermediate conversion to a8r8g8b8,
then we could update the CRC32 values even for the bit-exact tests.
But this would require us to always have at least generic C fast paths
enabled (because otherwise the use of "fetch -> combine -> writeback"
generic pipeline for over_8888_0565 would produce different CRC32
values in tests).

> 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.

IMHO it's not that terribly bad. The rounding to nearest 6-bit value
for the color components when converting them back from 8-bit already
introduces some significant deviation on average:

    0.5 * (1 / 2 ^ 6) = ~0.0078

> 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)

-- 
Best regards,
Siarhei Siamashka