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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Pixman mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pixman
