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