[Pixman] performance of bilinear_interpolation

[Chris Wilson]

On Wed, Oct 02, 2013 at 04:28:00AM +0300, Siarhei Siamashka wrote:
> On Fri, 27 Sep 2013 16:42:08 +0100
> Chris Wilson <chris at chris-wilson.co.uk> wrote:
> 
> > On Fri, Sep 27, 2013 at 01:17:45AM +0300, Siarhei Siamashka wrote:
> > > Unfortunately, all that I could record so far is a broken trace :-(
> > > Maybe somebody else will be more lucky? If anybody is interested, just
> > > go to http://manichord.com/opensign/ffdebug/ffscroll.html in Firefox,
> > > press ctrl-+ to zoom the page a bit and scroll it left/right for a
> > > while. The Firefox browser needs to be launched by the cairo-trace tool.
> > 
> > Lots of bugs in cairo-trace exposed by trying to record recent ff. :(
> > All appear to be fixed, and I've upload a firefox-canvas-scroll.trace to
> > the cairo-traces.git
> 
> Thanks for the fix. Firefox traces can be recorded now. I had a
> look at the firefox-canvas-scroll trace, but it does not fully
> represent this interesting use case. The trace has too much of
> blt (which eclipses the other operations), and too little of
> bits_image_fetch_bilinear_affine_pad_x8r8g8b8.
> 
> Profiling this trace shows:
> 
> 33.18%  cairo-perf-trac  libpixman-1.so.0.31.1 [.] sse2_blt.part.10
> 29.17%  cairo-perf-trac  libpixman-1.so.0.31.1 [.] sse2_composite_over_8888_8888
> 15.86%  cairo-perf-trac  libpixman-1.so.0.31.1 [.] sse2_fill
>  8.63%  cairo-perf-trac  libpixman-1.so.0.31.1 [.] bits_image_fetch_bilinear_affine_pad_x8r8g8b8
>  3.76%  cairo-perf-trac  liblzo2.so.2.0.0      [.] lzo2a_decompress
>  1.06%  cairo-perf-trac  libc-2.15.so          [.] __memcpy_ssse3
> 
> While running "perf record -p `pidof firefox" and profiling only the
> scrolling part in Firefox (without any possible initial setup overhead)
> seems to show no major blt usage:

Heh, I was happy to just see the affine_pad fetcher.
 
> 25.67%  firefox  libpixman-1.so.0.31.1 [.] sse2_composite_over_8888_8888
> 24.86%  firefox  libpixman-1.so.0.31.1 [.] bits_image_fetch_bilinear_affine_pad_x8r8g8b8
> 14.84%  firefox  libpixman-1.so.0.31.1 [.] sse2_fill
>  1.87%  firefox  libpixman-1.so.0.31.1 [.] sse2_blt.part.10
>  0.82%  firefox  libc-2.15.so          [.] __memcpy_ssse3
> 
> 
> I tried to record a new Firefox trace myself and also make it
> shorter, so that it is usable on much slower embedded systems:
> 
> https://github.com/ssvb/trimmed-cairo-traces/raw/86014d9a02d1/benchmark/t-firefox-canvas-swscroll.lzma
> 
> 35.55%  cairo-perf-trac  libpixman-1.so.0.31.1 [.] bits_image_fetch_bilinear_affine_pad_x8r8g8b8
> 18.83%  cairo-perf-trac  libpixman-1.so.0.31.1 [.] sse2_composite_over_8888_8888
>  7.71%  cairo-perf-trac  libc-2.15.so          [.] __memset_sse2
>  7.23%  cairo-perf-trac  liblzo2.so.2.0.0      [.] lzo2a_decompress
>  5.01%  cairo-perf-trac  libpixman-1.so.0.31.1 [.] sse2_fill
>  2.71%  cairo-perf-trac  libc-2.15.so          [.] __memcpy_ssse3
>  2.48%  cairo-perf-trac  libpixman-1.so.0.31.1 [.] sse2_blt.part.10
> 
> Additionally, Firefox is configured to use client side software
> rendering by setting gfx.xrender.enabled=false in about:config
> (in order to make it behave more like it behaves in Android).

That might have interesting effects such as the trace only using image
constructors rather than generic surface constructors, which would need
to be switched to make it run on any backend. The trick there though is
trying to detect the images that are being used for pixel loading and
avoid converting those. Fortunately the canvas is typically a fixed
size, so it looks like we want to convert

dict
  /width 356 set
  /height 391 set
  /format //RGB24 set
image

to

  << /width 356 /height 391 /content //COLOR >> surface

-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre