Thanks for the clarification. If each thread obtains an (exclusive) lock on the pixel region then the tasks will effectively be serialized and overall execution time will increase compared to a non-threaded implementation due to the threading overheads. (Queue manipulation, thread creation and context switching, etc). The main thread should lock the pixel region before pushing the tasks onto the work. Each task may then operate under the assumption that it has exclusive access to its tile. When the last task has completed the lock can be released. If this is already the case then please ignore as I have not had the opportunity of yet to review the code. -Dave -----Original Message----- From: gimp-developer-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:gimp-developer-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Sven Neumann Sent: Monday, 21 February 2005 11:01 AM To: David Bonnell Cc: Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx Subject: Re: [Gimp-developer] GIMP and multiple processors Hi, "David Bonnell" <dave@xxxxxxxxxxxxxxx> writes: > It sounds like the granularity of parallelism is too fine. That is, > each "task" is too short and the overhead of task dispatching (your > task queue processing, the kernels thread context switching, any IPC > required, etc.) is longer then the duration of a single task. > > I hit the same problem a decade and a half ago when I worked on > distributed parallel ray tracing systems for my post graduate > thesis. If each task is a pixel then you may want to consider > increasing this to a (configurable size) bundle of pixels. > Depending on the algorithm being parallelized the bundle may contain > contiguous pixels (if processing of each pixel requires > approximately uniform processor time) or a random set of pixels (if > there is, or can potentially be, significant variance in per-pixel > processing time). The task is not a single pixel but a single tile (that is usually a region of 64x64 pixels). GIMP processes pixel regions by iterating over the tiles. The multi-threaded pixel processor uses a configurable number of threads. Each thread obtains a lock on the pixel-region, takes a pointer to the next tile from the queue, releases the lock, processes the tile and starts over. This goes on until all tiles are processed. The main threads blocks until the queue is empty and all threads have finished their jobs. If a progress callback has been specified, the main thread wakes up regularily and updates the progress bar. Sven _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
