[Pixman] [PATCH/RFC] Use OpenMP for bilinear scaled fast paths

[Chris Wilson]

On Mon, 25 Jun 2012 02:00:27 +0300, Siarhei Siamashka <siarhei.siamashka at gmail.com> wrote:
> Does it actually make sense? I remember somebody was strongly opposing
> the idea of spawning threads in pixman in the past, but can't find
> this e-mail right now.

The only caveat from my point of view is that pixman_image_composite()
must be atomic as the current cairo_image_surface_t is meant to be
synchronous. Or at least API added so that I can serialise the
operations within cairo_image_surface_t. In the past, I believe we've
suggested grander schemes that that would require us to expose the
asynchronous nature to the user. However, simply using OpenMP to
parallise the kernels should not leak across the interface and so it is
acceptable. So it just boils down to whether this make maintenance
harder and interferes with future plans...

Is there a way to hint to OpenMP how many threads to use? As we know the
memory characteristics for most of the routines, do we not want to hint to
OMP not to use more threads than required to saturate memory bw? If it
was able to automatically fine tune itself, could we then not open up
more kernels for parallelisation? (Granted the scaling loops have the
worst performance characteristics, not even rivalling the
single-threaded performance of skia.)

Otherwise it's a big win for such a tiny patch! Just need to cross-check
that we don't introduce regression on the older single-core no-cache
chips. :(

Siarhei, just one more thing to consider: tiling. :)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre