On Mon, May 16, 2011 at 11:00 AM, Soeren Sandmann <[email protected]> wrote: > Matt Turner <[email protected]> writes: > >> I took the SSE2 code paths and modified them slightly to generate AVX >> code. AVX doesn't have integer operations like SSE2, so the range of >> 256-bit operations is mostly limited to copying pixels. >> >> Following this email are three patches: >> 1) AVX fetcher for x8r8g8b8 (a8 and r5g6b5 require integer unpack >> operations) >> 2) AVX blt, composite_copy_area and associated fast paths >> 3) AVX fill >> >> `make check` still passes all 18 tests. >> >> The only other bit of low-hanging fruit I see is >> composite_src_x888_8888, but perhaps there are more fast paths >> possible with AVX. > > Of the low-hanging fruit, this is probably the main one. One other might > be to compile pixman-sse2.c with -mavx in order to take advantage of the > VEX prefix for the integer SSE2 instructions. I'm not sure it would be > worth the build system complications though. > > Of the higher-hanging fruit that AVX could be used for, gradients is the > obvious candidate. Radial gradients in particular could become really > seriously faster. I think Andrea has some ideas about this. The > moonlight project has a copy of pixman with some gradient performance > improvements using SSE. See this git repository: > > https://github.com/mono/moon > > Maybe some of that code could be reused, but I think pixman master has > diverged a bit from when they forked. > > It would also be useful to redo the wide path used for 10bpc formats to > make it use single precision floating point instead. There is a branch > here: > > http://cgit.freedesktop.org/~ranma42/pixman/log/?h=wip/floatpipe4 > > that has a start on this. Clearly, if this branch of something similar > gets cleaned up and landed, AVX would be useful to accelerate it. > > Also, more generally, it would be interesting to move the test suite > from the current bit-exact standard towards a more close-enough > standard, so that floating point SIMD or GPUs or narrower integer > arithmetic could be used in cases where we currently rely on > precisely-8-bit integer arithmetic.
Sounds like a plan. It'll be fun to optimize this stuff for AVX. >> I played around with cairo-perf-trace on my Sandy Bridge, but wasn't >>able to see any improvements, which may be for any number of reasons, >>including but not limited to a) I don't know how to use >>cairo-perf-trace, b) AVX doesn't yield any noticeable improvements, c) >>the code needs to be better optimized. > > It's pretty likely that these operations are already close to the memory > bandwidth limit. There is a program in test/lowlevel-blt-bench that > attempts to measure performance of various operations relative to memory > bandwidth. Maybe it can produce some interesting results. I'll try to do more testing and figure out what's going on. Perhaps it's that since -march=native already turns on -mavx, I'm already seeing some kind of improvement in the SSE2 code which is masking the difference between it and the AVX paths. >> Still TODO are AVX cpuid detection and to figure out about SunCC >> support. > > Regarding SunCC, feel free to just support GCC initially. The various > types of compiler support really have to be maintained by people who use > those compilers regularly. Works for me. > I'll try to take a look at the patches later this week, but I don't have > any Sandy Bridge hardware atm., so I can't actually run it. In the mean time, I've pushed my patches to the avx-optimizations branch of git://anongit.freedesktop.org/~mattst88/pixman. I also added an AVX path for composite_src_x888_8888. (There is also a branch of Alpha/MVI optimization, but I'm not seeing any improvements, and write-hint prefetching seems to be a massive loss in terms of the number of cache-misses, although the numbers of cycles and instructions remain identical. No idea what's going on yet.) Thanks, Matt _______________________________________________ Pixman mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pixman
