On Wednesday 24 February 2010, Soeren Sandmann wrote: > Siarhei Siamashka <[email protected]> writes: > > The following patches add some new 32bpp ARM NEON optimized fast paths > > for the operations which are heavily used in the standard cairo-perf > > benchmarks. Profiling statistics has been posted earlier: > > http://people.freedesktop.org/~siamashka/files/20100216/pixman-0.17.6 > > It looks like most of these could be enabled in the ABGR case as > well. The pixbuf fast path also looks like it could be used as in the > [rpixbuf, a8b8g8r8] case.
Yes, you are right. I always keep forgetting about ABGR formats :) My only concern is about adding extra entries in the fast path tables for the operations which are likely to be never used. They are going to just decrease performance somewhat in the case when there is no fast path available and we fall back to the general case. More is not always better. For example, in the following trace the source of slowness was the use of general path 'fast_composite_over_n_8888_8888_ca' function. But going through all the fast path entries before reaching this fallback introduced additional overhead (can be seen as a high CPU usage in '_pixman_run_fast_path'): http://people.freedesktop.org/~siamashka/files/20100216/pixman-0.17.6/image-firefox-talos-gfx.png But I understand that fast path cache (which is coming to pixman eventually?) is going to improve the performance in such cases and this should basically become a non-issue. I also wonder if it makes sense to treat ARGB format as a canonical case, and do equivalent image format substitutions at the operators optimization stage? -- Best regards, Siarhei Siamashka _______________________________________________ Pixman mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pixman
