[Pixman] [PATCH 0/6] Improvements for the nearest scaling, second try

[Siarhei Siamashka]

On Friday 17 September 2010 22:45:56 Siarhei Siamashka wrote:
> This is the second revision of the nearest neigbour scaling patchset
> posted earlier:
> http://lists.freedesktop.org/archives/pixman/2010-September/000477.html
> 
> The changes since the last submission now include:
> - the move of the nearest scaling related macros to 'pixman-fast-path.h' is
>   done in a separate patch, as asked by Soeren
> - performance improvements for the nearest neighbor scaling when NONE or
> PAD repeat is set and *actually used*
> 
> The SSE2 implementation of over_8888_8888 is used here mostly as an example
> and may be rewritten or generalized later. Additionally, more ARM NEON and
> SSE2 optimized scaled fast paths will need to be added after these initial
> changes land to pixman git master.
> 
> Basically only REFLECT repeat support is now missing. And fast paths for
> any other nearest neighbour scaled compositing operations without mask
> should be relatively easy to add, also using SIMD optimizations when
> appropriate.
> 
> The same patches are also available at:
> http://cgit.freedesktop.org/~siamashka/pixman/log/?h=nearest-scaling-simd-2
> 0100917

Just forgot to mention. I also benchmarked a variety of scaling operations and
did not notice any unexpected performance regressions. Patched pixman runs
at the same speed or is (much) faster at least on my computer.

While doing benchmarks, I also noticed a weird performance problem. If the
source image has PAD repeat, simple identity transform and the operation
does not try to fetch pixels outside source image (standard unscaled case),
pixman unexpectedly hits some slow path. I'm going to investigate this
problem a bit later.

Another minor practical problem is that the following patches from Soeren
unfortunately conflict with my patchset:
http://lists.freedesktop.org/archives/pixman/2010-September/000508.html
http://lists.freedesktop.org/archives/pixman/2010-September/000537.html

That's why it probably makes sense to try pushing all the needed infrastructure
changes as soon as possible and be done with them.

Also the new flags are being introduced or changed from time to time, like in
this patch:
http://lists.freedesktop.org/archives/pixman/2010-September/000531.html
Maybe it makes sense to already reserve flags for 90/180/270 degrees rotation
right now in order to avoid patch clashes later?

-- 
Best regards,
Siarhei Siamashka
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/pixman/attachments/20100918/137b7cae/attachment.pgp>