Re: [Pixman] [PATCH 1/7] Refactor calculation of cover flags

2015-09-03 Thread Siarhei Siamashka
On Thu, 3 Sep 2015 13:53:26 +0300 Pekka Paalanen wrote: > On Thu, 27 Aug 2015 11:45:22 +0100 > "Ben Avison" wrote: > > > On Thu, 27 Aug 2015 03:55:07 +0100, Siarhei Siamashka > > wrote: > > >> -/* Expand the source

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

2015-09-03 Thread Siarhei Siamashka
On Thu, 03 Sep 2015 13:59:07 +0100 "Ben Avison" wrote: > On Thu, 03 Sep 2015 11:13:25 +0100, Pekka Paalanen > wrote: > > Unless, you go and change the implementation meaning of Pixman's cover > > flags which, reading your other reply, is what you

Re: [Pixman] [PATCH 1/7] Refactor calculation of cover flags

2015-09-03 Thread Pekka Paalanen
On Thu, 27 Aug 2015 11:45:22 +0100 "Ben Avison" wrote: > On Thu, 27 Aug 2015 03:55:07 +0100, Siarhei Siamashka > wrote: > >> -/* Expand the source area by a tiny bit so account of different > >> rounding that > >> - * may happen

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

2015-09-03 Thread Pekka Paalanen
On Wed, 02 Sep 2015 20:15:26 +0100 "Ben Avison" wrote: > On Wed, 02 Sep 2015 12:56:40 +0100, Pekka Paalanen > wrote: > > Right. I looked at fast_bilinear_cover_iter_init() and > > fast_fetch_bilinear_cover() -> fetch_horizontal(), and yes, that

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

2015-09-03 Thread Pekka Paalanen
On Wed, 02 Sep 2015 20:34:56 +0100 "Ben Avison" wrote: > On Wed, 02 Sep 2015 14:03:01 +0100, Pekka Paalanen > wrote: > > I am still a tiny bit struggling with why 31 and not 32, but it does > > add up. > > Maybe the reasoning in the comments in

Re: [Pixman] [PATCH v3] test: add fence-image-self-test

2015-09-03 Thread Pekka Paalanen
On Wed, 02 Sep 2015 17:14:07 +0100 "Ben Avison" wrote: > On Wed, 02 Sep 2015 09:15:24 +0100, Pekka Paalanen > wrote: > > Changes in v3: > > > > - Do not print progress messages unless VERBOSE environment variable is > > set. Avoid spamming the

[Pixman] [PATCH 1/4] Change conditions for setting FAST_PATH_SAMPLES_COVER_CLIP flags

2015-09-03 Thread Ben Avison
As discussed in http://lists.freedesktop.org/archives/pixman/2015-August/003905.html the 8 * pixman_fixed_e adjustment which was applied to the transformed coordinates is a legacy of rounding errors which used to occur in old versions of Pixman, but which no longer apply. For any affine

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

2015-09-03 Thread Pekka Paalanen
On Wed, 2 Sep 2015 20:35:59 +0100 Ben Avison wrote: > This test aims to verify both numerical correctness and the honouring of > array bounds for scaled plots (both nearest-neighbour and bilinear) at or > close to the boundary conditions for applicability of "cover" type

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

2015-09-03 Thread Ben Avison
On Thu, 03 Sep 2015 11:13:25 +0100, Pekka Paalanen 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

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

2015-09-03 Thread Ben Avison
On Thu, 03 Sep 2015 17:14:05 +0100, Siarhei Siamashka wrote: On Thu, 03 Sep 2015 13:59:07 +0100 "Ben Avison" wrote: Previously, the flag definition was overly cautious, resulting in some cases which could have been handled by cover paths

[Pixman] [PATCH 3/4] armv7/mips/sse2: Make bilinear cover fast paths use COVER_CLIP_TIGHT flag

2015-09-03 Thread Ben Avison
This patch affects all functions defined by the macro FAST_BILINEAR_MAINLOOP_INT, which can be identified by the fact that their names start with the string "fast_composite_scaled_bilinear". These are currently found in arm-neon, mips-dspr2 and sse2 implementations. The inner pixel loop for these

[Pixman] [PATCH 4/4] pixman-fast-path: Make bilinear cover fetcher use COVER_CLIP_TIGHT flag

2015-09-03 Thread Ben Avison
The bilinear cover fetcher was implemented with similar assumptions to FAST_BILINEAR_MAINLOOP_INT - that for all transformed destination coordinates, you could divide by 2^16, round down and add 1, and still be within the source image. This patch effectively reverses this - dividing by 2^16,