<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">&lt;<a href="mailto:siarhei.siamashka@gmail.com">siarhei.siamashka@gmail.com</a>&gt;</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>&gt; On Tue, Feb 8, 2011 at 2:23 PM, Siarhei Siamashka<br>&gt;<br>&gt; &lt;<a href="mailto:siarhei.siamashka@gmail.com">siarhei.siamashka@gmail.com</a>&gt; wrote:<br>
&gt; &gt; On Tuesday 08 February 2011 06:52:02 cooolheater wrote:<br>&gt; &gt;&gt; Hi,<br>&gt; &gt;&gt; I&#39;m developer of mobile browser using webkit with cairo library.<br>&gt; &gt;&gt; Recently, I did performance comparing test between cairo 1.10.02 and<br>
&gt; &gt;&gt; skia library.<br>&gt; &gt;<br>&gt; &gt; Thanks for your benchmarking data. What kind of hardware have you used<br>&gt; &gt; for running this benchmark? And because you are using cairo image<br>&gt; &gt; backend, the version of pixman library is also important because it is<br>
&gt; &gt; actually doing all the scaling work.<br>&gt; &gt;<br>&gt; &gt;&gt; The performance of compstion and rotating seems similar,<br>&gt; &gt;<br>&gt; &gt; Performance of rotation in pixman should be horrible right now, don&#39;t<br>
&gt; &gt; know if I should be happy to know that skia seems to be just as bad :)<br>&gt; &gt;<br>&gt; &gt; What kind of rotation are you are interested in? The following patches<br>&gt; &gt; should help with some types of rotation, and can be extended if needed:<br>
&gt; &gt; <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>&gt; &gt;<br>&gt; &gt;&gt; but scaling performance of cairo library seems quite low.<br>
&gt; &gt;<br>&gt; &gt; On non-SIMD capable processors, cairo/pixman should have bilinear scaling<br>&gt; &gt; performing roughly as fast as the other good implementations, so I assume<br>&gt; &gt; that some kind of SIMD is supported on your target system.<br>
&gt; &gt;<br>&gt; &gt; A problem with bilinear scaling performance in pixman is that it does not<br>&gt; &gt; have SIMD optimizations yet. That&#39;s something that I&#39;m currently looking<br>&gt; &gt; into, at least for ARM NEON.<br>
&gt; &gt;<br>&gt; &gt; Also your benchmarks show that the overhead before reaching actual<br>&gt; &gt; scaling code is much lower with skia as can be seen for very small sizes<br>&gt; &gt; of images. It&#39;s still questionable how much such overhead affects real<br>
&gt; &gt; use cases, but I&#39;m expressing concern here from time to time whenever I<br>&gt; &gt; see the patches which seem to be increasing this overhead in pixman more<br>&gt; &gt; than necessary.<br>&gt;<br>&gt; Profile data would be needed to confirm this, but my guess is that most of<br>
&gt; 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>&gt; &gt; The only surprising thing in your data is that skia seems to have really<br>&gt; &gt; poor performance for nearest scaling, but probably they just primarily<br>&gt; &gt; focused on making bilinear scaling fast.<br>
&gt;<br>&gt; The cairo bilinear/nearest ratio looks more surprising to me.<br>&gt; What is the reason for a 40x slowdown?<br>&gt; I didn&#39;t expect the generic path to be so much slower than fast paths.<br><br></div>It&#39;s more like 35x slowdown, but this is not very surprising. For nearest<br>
scaling it&#39;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&#39;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&#39;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>