On Wed, 13 Feb 2013 01:08:20 +0100 [email protected] (Søren Sandmann) wrote:
> Ben Avison <[email protected]> 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 _______________________________________________ Pixman mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pixman
