[Pixman] [PATCH 0/4] Reworked nearest-scaled-cover ARMv6 fast paths

[Ben Avison]

This series was prompted by this comment from Søren:

> ==================================================================
> 0030:	nearest_scaled_cover src_8888_8888
> 0031:	four more
> 0032:	nearest_scaled_cover
> ==================================================================
>
> I can't say I'm a big fan of these patches. They are essentially
> workarounds for the longstanding problem that pixman sometimes won't
> pick the fastest code for some operations. In this case the general
> iter based code will be faster then the C code in pixman-fast-path.c
> because the iter code will use assembly fetchers.
> 
> As a result you end up with a bunch of partial reimplementations of
> general_composite_rect() inside pixman-arm-simd.c.
>
> Maybe we need to admit failure and make general_composite_rect()
> available for other implementations to use. Essentially we would
> officially provide a way for implementations to say: My iterators are
> faster than pixman-fast-path.c for these specific operations, so just
> go directly to general_composite_rect().
>
> It's definitely not a pleasant thing to do, but given that nobody is
> likely to have the time/skill combination required to do the necessary
> redesign of pixman's fast path system, it might still be preferable to
> to do this instead of duplicating the code like these patches do.
>
> With a setup like that, we could also fix the same issue for the
> bilinear SSSE3 fetchers and possibly other cases.

First thing to note is that if you want to try the complete series, you'll
need at least the ARMv6 nearest fetcher patches installed - at the time of
writing they've not been committed either:

http://patchwork.freedesktop.org/patch/49963/
http://patchwork.freedesktop.org/patch/49920/
http://patchwork.freedesktop.org/patch/49921/
http://patchwork.freedesktop.org/patch/49922/

As described in the individual patches, I'm actually suggesting we *don't*
use this approach, since using general_composite_rect seems to increase the
overhead so much that it's no longer just L1 tests that show regressions.
However, I wanted to post these anyway:
a) as a record of having tried and rejected this approach, and
b) because the first patch may still be useful for the SSSE3 fetchers Søren
   mentions, or Oded's VMX over_n_8888 case.

Ben Avison (4):
  Expose general_composite_rect outside pixman-general.c
  armv6: Add nearest-scaled-cover src_8888_8888 fast path
  armv6: Add four more nearest-scaled-cover fast paths
  armv6: Add nearest-scaled-cover src_0565_0565 fast path

 pixman/pixman-arm-common.h          |   18 +++++++++
 pixman/pixman-arm-simd-asm-scaled.S |    4 ++
 pixman/pixman-arm-simd-asm-scaled.h |   69 ++++++++++++++++++++++++++++++-----
 pixman/pixman-arm-simd.c            |   55 ++++++++++++++++++++++++++++
 pixman/pixman-general.c             |    8 ++--
 pixman/pixman-private.h             |    9 +++++
 6 files changed, 150 insertions(+), 13 deletions(-)

-- 
1.7.5.4