[cairo] scaling performance test of cairo library

[cooolheater]

Thank you for your kind explanation.
I used pixman-0.21.4 for testing.
As you guessed, we are using SIMD and are finding method for NEON
acceleration.
Could you let me know the bilinear scaling interfaces in pixman and
where the SIMD optimization will be applied?

On Tue, Feb 8, 2011 at 11:39 PM, Siarhei Siamashka <
siarhei.siamashka at gmail.com> wrote:

>  On Tuesday 08 February 2011 16:02:27 Andrea Canciani wrote:
> > On Tue, Feb 8, 2011 at 2:23 PM, Siarhei Siamashka
> >
> > <siarhei.siamashka at gmail.com> wrote:
> > > On Tuesday 08 February 2011 06:52:02 cooolheater wrote:
> > >> Hi,
> > >> I'm developer of mobile browser using webkit with cairo library.
> > >> Recently, I did performance comparing test between cairo 1.10.02 and
> > >> skia library.
> > >
> > > Thanks for your benchmarking data. What kind of hardware have you used
> > > for running this benchmark? And because you are using cairo image
> > > backend, the version of pixman library is also important because it is
> > > actually doing all the scaling work.
> > >
> > >> The performance of compstion and rotating seems similar,
> > >
> > > Performance of rotation in pixman should be horrible right now, don't
> > > know if I should be happy to know that skia seems to be just as bad :)
> > >
> > > What kind of rotation are you are interested in? The following patches
> > > should help with some types of rotation, and can be extended if needed:
> > > http://lists.freedesktop.org/archives/pixman/2011-February/000970.html
> > >
> > >> but scaling performance of cairo library seems quite low.
> > >
> > > On non-SIMD capable processors, cairo/pixman should have bilinear
> scaling
> > > performing roughly as fast as the other good implementations, so I
> assume
> > > that some kind of SIMD is supported on your target system.
> > >
> > > A problem with bilinear scaling performance in pixman is that it does
> not
> > > have SIMD optimizations yet. That's something that I'm currently
> looking
> > > into, at least for ARM NEON.
> > >
> > > Also your benchmarks show that the overhead before reaching actual
> > > scaling code is much lower with skia as can be seen for very small
> sizes
> > > of images. It's still questionable how much such overhead affects real
> > > use cases, but I'm expressing concern here from time to time whenever I
> > > see the patches which seem to be increasing this overhead in pixman
> more
> > > than necessary.
> >
> > Profile data would be needed to confirm this, but my guess is that most
> of
> > the overhead is actually in cairo.
>
> Well, having another look at the code, I think that the results for small
> image sizes are not reliable. The timer gets started/stopped just around
> cairo_paint() and does not take into account the initial setup. Depending
> on
> implementation details, the actual work processing these scaling settings
> parameters may be either postponed till the paint operation itself, or done
> immediately.
>
> Also the use of scale factor 2.0 is not a very good choice for general
> scaling
> performance comparison. Because theoretically it may be special cased and
> work
> faster than scaling with arbitrary scale factors in either of the
> libraries.
>
> > > The only surprising thing in your data is that skia seems to have
> really
> > > poor performance for nearest scaling, but probably they just primarily
> > > focused on making bilinear scaling fast.
> >
> > The cairo bilinear/nearest ratio looks more surprising to me.
> > What is the reason for a 40x slowdown?
> > I didn't expect the generic path to be so much slower than fast paths.
>
> It's more like 35x slowdown, but this is not very surprising. For nearest
> scaling it's just a single read from one place and a single write to
> another
> place per pixel. For bilinear scaling, in order to get a single destination
> pixel, we are reading 4 source pixels, recalculating weights, doing lots of
> multiplications, additions and shifts. That's a lot more operations and
> being
> that much slower is pretty normal for a general C implementation. SIMD is
> expected to perform really well on such workloads, but surely can't match
> the
> performance of nearest scaling either.
>
> --
> Best regards,
> Siarhei Siamashka
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cairographics.org/archives/cairo/attachments/20110209/03c12fe3/attachment.html>