[Pixman] [PATCH 0/2] 7-bit bilinear interpolation precision

[Siarhei Siamashka]

On Tue, Jun 26, 2012 at 6:04 PM, Søren Sandmann <sandmann at cs.au.dk> wrote:
> Siarhei Siamashka <siarhei.siamashka at gmail.com> writes:
>
>> Also 7-bit bilinear interpolation precision still allows a nice SSSE3
>> optimization, which can be implemented later to get even more speed.
>
> Presumably you mean pmaddubsw,

Yes

> but isn't it a problem that the weights
> can go from 0 to 128 inclusive? That is, if one weight is 0, the other
> is 128, which means it doesn't actually fit in seven bits. So unless I
> am missing something, pmaddubsw can't be used without a test for 0.

For 8-bit precision we had the same problem with weights going from 0
to 256 inclusive and it is already handled here:
    http://cgit.freedesktop.org/pixman/tree/pixman/pixman-inlines.h?id=pixman-0.26.0#n881

>> But the patches need a lot more testing on different hardware.
>
> Running the test suite on ppc64, ARM, x86-64 with various
> implementations disabled revealed no problems for me.

Thanks. I'll still try to run some more tests and review the code
again to check for any possible leftover magic constants hardcoding 8
bits of bilinear interpolation precision.

There is also one thing to investigate. It was likely also a problem
earlier, but may become worse when going to lower interpolation
precision. Right now the position between pixels is rounded down by
throwing away lowest bits when converting it to bilinear weight. It
may potentially cause image drift to the left/upper side if the image
is scaled up/down repeatedly really a lot. Maybe pixman_fixed_1 / 2
constant needs to be adjusted here (and in the other places too) to
ensure more correct rounding:
    http://cgit.freedesktop.org/pixman/tree/pixman/pixman-inlines.h?id=pixman-0.26.0#n811
But I guess it's better to write a test program to check whether such
effect exists.

-- 
Best regards,
Siarhei Siamashka