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

[Ben Avison]

On Thu, 03 Sep 2015 11:13:25 +0100, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> Unless, you go and change the implementation meaning of Pixman's cover
> flags which, reading your other reply, is what you are doing. I'm
> finally starting to see it.

Glad the penny has dropped! The issue has been muddied somewhat by the
8*epsilon border. Perhaps I should have reposted the series as soon as it
became clear what the history was in that respect.

(from your other post on this thread)
> This is *not* for protecting against out-of-bounds access, but this is
> allowing for the extreme cases where a cover path is still
> *theoretically* possible. (Ignoring what the COVER flags actually mean
> in Pixman implementation.)

Yes. Pixman as a whole should be able to handle any coordinates without
bounds violations. The COVER_CLIP flags just determine the threshold
coordinates at which it chooses to use a cover path rather than the
appropriate repeat path (PAD, NONE, NORMAL or REFLECT); while you would
get the correct mathematical result even if always use the repeat path,
the cover path is very likely to be faster because it will be implemented
in a way that assumes it doesn't need to do bounds checking (because the
COVER_CLIP calculation has effectively done the bounds check for it).

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 but cover paths
for its nearest tests. However, we have to be careful when adjusting the
flag calculations, as the cases where bounds violations occur may only be
1*epsilon wide, and so would have a high chance of not being detected by
the previous test suite in a reasonable length of time - hence the need
for a new test program.

When EXACT is set, cover-test only performs operations which are
theoretically achievable with a cover path (and in fact, they *are* all
achieved with a cover path if you apply all my patches). When it isn't
set, some operations will stray into territory that definitely needs a
repeat path. The size of the the fuzz factors that are applied to the
coordinates was set large enough, using knowledge of the 8*epsilon factor
in the old definition of the COVER_CLIP flags, that we should exercise
both cover and repeat paths right up to the coordinate limits at which
either old or new definition will allow them to be used.

>> Of course, I've now changed cover-test so it doesn't do randmemset
>> straight into fenced images anyway (due to needing to handle systems
>> with different memory page sizes) so this is no longer an issue.
>
> D'oh, of course, that's why Oded didn't see a segfault. But he did say
> the CRC does not match on PPC64, neither LE nor BE.

Just to be clear, is that still an issue after I fixed the DST_HEIGHT
SRC_HEIGHT bug?

Ben