[Pixman] [PATCH 0/7] Faster pipelined ARM NEON bilinear scalers: 'src_8888_8888' and 'src_8888_0565'

[Siarhei Siamashka]

On Sun, Apr 10, 2011 at 12:31 AM, Soeren Sandmann <sandmann at cs.au.dk> wrote:
> Siarhei Siamashka <siarhei.siamashka at gmail.com> writes:
>
>> Additional use for 'src_8888_0565' bilinear scaline function is the
>> potential support for fast scaled YUV->RGB conversion. It may be
>> beneficial to first perform unscaled YUV->x8r8g8b8 conversion and then
>> scale the result (it can be easily an overall performance win for
>> upscaling).
>
> That's interesting. Similar to the 565->565 case, I guess the
> performance improvement is because fewer color conversions are required
> relative to the case where the YCbCr image is scaled first and then
> converted.

That's just a guess which needs to be proven by benchmarks, and the
final outcome is not clear yet :) For using bilinear filter with
YUV420 image, we only need to interpolate 1.5 color components on
average per pixel (if scaling is done before getting rid of
subsampling). For RGB image, we need to interpolate 3 color components
per pixel (or even 4 as with the current pixman NEON code, which
wastes extra time on non-existing alpha channel). But when using
nearest scaling for the upscaling case, the two pass processing looks
like a clear winner to me.

> As mentioned earlier:
>
>    http://lists.freedesktop.org/archives/pixman/2011-March/001093.html
>
> I think converting to rgb before scaling is actually the more correct
> approach, even though an extra interpolation filter is involved.

I still don't agree, but decided not to comment on that earlier,
before the performance impact is fully understood for both
alternatives.

> I definitely was worried that it might be a performance problem,
> though. If converting to rgb first can actually be a performance
> improvement, that's good news.

It's too early to make any conclusions. And there is also downscaling
to consider. If aiming for best performance in each case, then using
different scaling algorithms for upscaling and downscaling may be
necessary. And this is not so good for testing and general
consistency.

> Doing it that way also solves the practical problem that the general
> fetch/combine/store pipeline can't easily be modified to do color
> conversion after scaling, and so fast paths might have had to use
> different algorithm than the general path.
>
> Also, a bilinear src_8888_0565 scaler would also be a convenient place
> to add dithering, which is something that youtube on my netbook could
> decidedly benefit from.
>
> So, basically, I like this idea a lot.

Yes, I also like it, because it looks much easier to implement. And
extra dithering would be indeed nice to have, but I wonder how can it
be added to pixman in a consistent way.

-- 
Best regards,
Siarhei Siamashka