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.


-----Original Message-----
[mailto:[EMAIL PROTECTED] On Behalf Of Sven
Sent: Monday, 21 February 2005 11:01 AM
To: David Bonnell
Subject: Re: [Gimp-developer] GIMP and multiple processors


"David Bonnell" <[EMAIL PROTECTED]> 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.

Gimp-developer mailing list

Gimp-developer mailing list

Reply via email to