On Mon, 25 Jun 2012 02:00:27 +0300, Siarhei Siamashka <siarhei.siamas...@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 _______________________________________________ Pixman mailing list Pixman@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pixman