[Pixman] [PATCH 06/12] vmx: implement fast path vmx_composite_over_n_8888_8888_ca
Pekka Paalanen
ppaalanen at gmail.com
Wed Jul 15 04:59:36 PDT 2015
On Tue, 14 Jul 2015 11:41:25 +0300
Siarhei Siamashka <siarhei.siamashka at gmail.com> wrote:
> On Thu, 2 Jul 2015 13:04:11 +0300
> Oded Gabbay <oded.gabbay at gmail.com> wrote:
>
> > POWER8, 8 cores, 3.4GHz, RHEL 7.1 ppc64le.
> >
> > reference memcpy speed = 24764.8MB/s (6191.2MP/s for 32bpp fills)
*Very* stable memcpy speed, comparing to patch 7. Impressive.
> >
> > Before After Change
> > ---------------------------------------------
> > L1 61.92 244.91 +295.53%
> > L2 62.74 243.3 +287.79%
> > M 63.03 241.94 +283.85%
> > HT 59.91 144.22 +140.73%
> > VT 59.4 174.39 +193.59%
> > R 53.6 111.37 +107.78%
> > RT 37.99 46.38 +22.08%
> > Kops/s 436 506 +16.06%
> >
> > cairo trimmed benchmarks :
> >
> > Speedups
> > ========
> > t-xfce4-terminal-a1 1540.37 -> 1226.14 : 1.26x
> > t-firefox-talos-gfx 1488.59 -> 1209.19 : 1.23x
> >
> > Slowdowns
> > =========
> > t-evolution 553.88 -> 581.63 : 1.05x
> > t-poppler 364.99 -> 383.79 : 1.05x
> > t-firefox-scrolling 1223.65 -> 1304.34 : 1.07x
> >
> > Signed-off-by: Oded Gabbay <oded.gabbay at gmail.com>
>
> Acked-by: Siarhei Siamashka <siarhei.siamashka at gmail.com>
>
Hi,
why are there slowdowns up to 7%?
Can the cost of adding more entries to the fast path table be that
much, or is something else going on?
Or if we don't care about that, why?
If you have no idea, maybe check the "all" set of lowlevel-blt-bench if
you can find unrelated operations slowing down for some obscure reason.
I suppose could also see if adding the same amount of fast path table
entries that will never match would cause the same slowdowns as this
patch.
Thanks,
pq
More information about the Pixman
mailing list