[Pixman] [PATCH] test: Add cover-test

[Ben Avison]

On Thu, 03 Sep 2015 17:14:05 +0100, Siarhei Siamashka <siarhei.siamashka at gmail.com> wrote:
> On Thu, 03 Sep 2015 13:59:07 +0100 "Ben Avison" <bavison at riscosopen.org> wrote:
>> Previously, the flag definition was overly cautious, resulting in some
>> cases which could have been handled by cover paths instead being sent
>> to repeat paths. I first encountered this myself with
>> lowlevel-blt-bench, which routinely used repeat paths for its bilinear
>> tests
>
> Oh, this was actually intended. The bilinear scaling benchmark in
> the lowlevel-blt-bench program tries to stress the use case, where
> we are fetching pixels from the outside of the source image a little
> bit. The reason is that this is quite typical for bilinear scaling
> and that's how it is designed to work.
>
> If this whole ordeal with the new COVER flag interpretation was just
> a way to make it run fast in lowlevel-blt-bench, then this new
> interpretation may not make much real practical sense.

That was just where it started... I should maybe explain that I
encountered it when I was writing bilinear fetchers for ARMv6, which (at
the time (*)) only handled the COVER case. This meant that
lowlevel-blt-bench was useless to me as it stood, because my COVER
fetchers were never selected, and it was important to me because I rely
on it to be able to compare different implementations (for example to
select the best prefetch distance). I was worried there might be
objections to changing lowlevel-blt-bench, and I also knew that I
followed different code paths for different scale factors (which are
fixed in lowlevel-blt-bench), many of which were so extreme that the
L1/L2/M/HT/VT/RT/R tests of lowlevel-blt-bench no longer made sense - so
that's how I came to write affine-bench.

But while writing affine-bench, it became apparent that it's really
complicated from a high level caller's point of view to construct a
transformation matrix that's guaranteed to hit a COVER path - and it
requires knowledge of details of the internal implementation of the guts
of Pixman, even after you deal with the obsolete 8*pixman_fixed_e
adjustment. This seemed wrong to me; I can imagine applications might
well want to use Pixman to scale between pixel centres rather than pixel
edges, and to expect such an application to know whether to exclude the
left pixel, or the right pixel, or both, or neither, and the same in the
vertical direction (for which the rules were often different) in order to
get the best performance is surely unreasonable.

Ben

(*) Actually, I've been revisiting this recently, and for various reasons
I've added repeat support to these fetchers. But now I'm getting a long
way ahead of myself...