On Sun, Apr 10, 2011 at 12:31 AM, Soeren Sandmann <[email protected]> wrote: > Siarhei Siamashka <[email protected]> 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 _______________________________________________ Pixman mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pixman
