Re: [Gimp-developer] Re: optional scaling in the save dialog?
Joao S. O. Bueno Calligaris wrote: - Initially using X memory duplicate image - now using x * 2 memory. That shouldn't be true. The vast majority of the memory used by the duplicate is tile data which GIMP simply copy-on-write shares between the original and the duplicate. (Unless COW stuff got broken since I last checked, but I doubt it.) --Adam -- Adam D. Moss - [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] optional scaling in the save dialog?
Hi, Gerhard Gauling [EMAIL PROTECTED] writes: I agree with you, but wouldn't it be nice to have once on a day something similar to the file automation dialog in Photoshop? There one can choose for example contact sheet or batch processing. In batch processing one can select an action (i.e. gimp-script), a folder for loading the files for processing and one for saving them, and in which kind the naming is to be managed, and so on. I think, this could be something for later plans in the far future. I think this is something that can be developed completely independently as a GIMP plug-in. And sure, I am waiting for someone to write this for several years already. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and multiple processors
Hi, Daniel Egger [EMAIL PROTECTED] writes: Hm, there's still no idea floating around how to benchmark. There are very clear ideas on how to do it. Someone just needs to sit down and write the script (or dig out script-fu-bench.scm which is what we used to use a long time ago). I'd rather have some microbenchmark that delivers reproducible results than only being able to say hey, it feels faster... You'd still do me a favor if you would try current CVS and told me whether it feels faster or not. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] ANNOUNCE: gimp-help-2 0.7
Hi, we released a new snapshot (0.7) of the user manual, which is mainly a bugfix snapshot. You can download this snapshot from ftp.gimp.org: ftp://ftp.gimp.org/pub/gimp/help/testing/gimp-help-2-0.7.tar.gz There is also a browsable up to date CVS version online on: http://docs.gimp.org We've also released PDF versions of the manual, which are also available at http://docs.gimp.org. Please keep in mind, that the PDF versions are only for testing purposes. Documentation in this release is available for English, French, Chinese, German, Swedish and Czech. This snapshot includes new screenshots for chinese content, fixes for the build system, stylesheets and the content. Thanks for everyone who contributed to this manual. Happy Gimping, Roman -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Re: optional scaling in the save dialog?
Hi, [EMAIL PROTECTED] (2005-02-20 at 0203.45 -0200): Let X bre a Huge Amount of Memory (tm) taken by said image, and Y be A Couple Kilobytes (tm) used by scaled down version Your proccess: - Initially using X memory duplicate image - now using x * 2 memory. I assume there is Copy On Write, thus delaying real memory usage (and the bandwidth too) until the data changes. Lets see COW at work: Just after launching gimp: total used free sharedbuffers cached Mem:514308 04 69904 0 6180 137996 -/+ buffers/cache: 300228 214080 Swap: 264144 63140 201004 2000*2000 image created and plasma filter run: total used free sharedbuffers cached Mem:514308 500864 13444 0 6336 138012 -/+ buffers/cache: 356516 157792 Swap: 264144 63140 201004 script-fu console launched: total used free sharedbuffers cached Mem:514308 503428 10880 0 6372 138268 -/+ buffers/cache: 358788 155520 Swap: 264144 63140 201004 gimp-image-duplicate invoked once, id reported is 2: total used free sharedbuffers cached Mem:514308 503000 11308 0 6532 138260 -/+ buffers/cache: 358208 156100 Swap: 264144 63140 201004 Invoked 3 more times (ids 3, 4 and 5), to check the apps is not reusing memory it already owns: total used free sharedbuffers cached Mem:514308 503008 11300 0 6568 138260 -/+ buffers/cache: 358180 156128 Swap: 264144 63140 201004 OK, pushing the limits, so invoked 46 times more (ids 6 to 51): total used free sharedbuffers cached Mem:514308 504308 1 0 7284 136336 -/+ buffers/cache: 360688 153620 Swap: 264144 63364 200780 Used swap and mem (after removing buffers and cache) numbers seem pretty stable, just mimimal increases in both, some KB reduction sometimes (other app releasing mem probably). By your rule, the machine should be crawling now due the 50 copies. Just the pixels are 50 * 2000 * 2000 * 3 = 600 * 10^6, more than the physical RAM. (__) (oo) Moo Super Powers /---\/ / | || * |||| ~~~~ GSR ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] optional scaling in the save dialog?
Sven Neumann wrote: Gerhard Gauling [EMAIL PROTECTED] writes: In batch processing one can select an action (i.e. gimp-script), a folder for loading the files for processing and one for saving them, and in which kind the naming is to be managed, and so on. [...] I think this is something that can be developed completely independently as a GIMP plug-in. And sure, I am waiting for someone to write this for several years already. That's pretty much what David's Batch Processor does, except that is uses a fixed gui to control a number of common ops, instead of requiring a script to perform general ops. http://members.ozemail.com.au/~hodsond/dbp.html -- David Hodson -- this night wounds time ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and multiple processors
On 20.02.2005, at 14:09, Sven Neumann wrote: There are very clear ideas on how to do it. Hm, must have missed that... Someone just needs to sit down and write the script (or dig out script-fu-bench.scm which is what we used to use a long time ago). You'd still do me a favor if you would try current CVS and told me whether it feels faster or not. Okee, I'm warming up the machine right now. This'll take a while though because I need to recompile quite some stuff. I'll do that in 32bit mode if you don't mind... Servus, Daniel PGP.sig Description: This is a digitally signed message part
Re: [Gimp-developer] GIMP and multiple processors
Sven Neumann wrote: Daniel Egger [EMAIL PROTECTED] writes: Hm, there's still no idea floating around how to benchmark. There are very clear ideas on how to do it. Someone just needs to sit down and write the script (or dig out script-fu-bench.scm which is what we used to use a long time ago). It would be nice to have a copy of that old script-fu-bench.scm script. I used to have a copy with one of my versions of GIMP. It isn't in CVS and I can't find it on the net. If someone has the script I'd like to get a copy of it. Even if we had the old script-fu-bench script around I don't think its the best choice to do the benchmarking tests which are currently needed. It is something I (or someone knowledgeable in Script-Fu or another GIMP scripting language) could write. It would be helpful to have a list of GIMP features/functions to use which would make call the code which needs to be benchmarked. -- Cheers! Kevin. (http://www.interlog.com/~kcozens/) Owner of Elecraft K2 #2172|What are we going to do today, Borg? E-mail:kcozens at interlog dot com|Same thing we always do, Pinkutus: Packet:[EMAIL PROTECTED]| Try to assimilate the world! #include disclaimer/favourite | -Pinkutus the Borg ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Builds with SRCDIR != OBJDIR broken
Hija, while building GIMP for the threading test I noticed that builds where the source dir is not the object directory are slightly broken; in particular the intlfoo magic in the tips directory doesn't take the SRCDIR into account and thus failes badly and the following (generated) files are built in OBJDIR but searched for in SRDIR: libgimpthumb/gimpthumb-enums.c libgimpwidgets/gimpwidgetsmarshal.c libgimp/gimpenums.c app/core/gimpmarshal.h Anyone here who can fix that with some Makefile-fu? Servus, Daniel PGP.sig Description: This is a digitally signed message part
Re: [Gimp-developer] Re: Re: optional scaling in the save dialog?
That is great. I did not know that the GIMP could reuse tiles from one image to another. Actually, I didi not tought this was done even from a layer to another - that explains why adding new layers to large images goes so smoothly. I am more than happy. How does this memory usega behave when one apply a transform (scale down in this case), ont he image, or on a copy of it? Because Mateusz wrote me that the disabling undo improved the performance of the operation. Maybe it is just the beneffits f not having X allocated anymore, and therefore no more swaps after the scale down. Regards, JS -- On Sunday 20 February 2005 11:43, GSR - FR wrote: I assume there is Copy On Write, thus delaying real memory usage (and the bandwidth too) until the data changes. Lets see COW at work: (...) ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Builds with SRCDIR != OBJDIR broken
Hi, Daniel Egger [EMAIL PROTECTED] writes: while building GIMP for the threading test I noticed that builds where the source dir is not the object directory are slightly broken; in particular the intlfoo magic in the tips directory doesn't take the SRCDIR into account and thus failes badly and the following (generated) files are built in OBJDIR but searched for in SRDIR: libgimpthumb/gimpthumb-enums.c libgimpwidgets/gimpwidgetsmarshal.c libgimp/gimpenums.c app/core/gimpmarshal.h Anyone here who can fix that with some Makefile-fu? make distcheck builds with srcdir != builddir so this should work and is tested quite often. Why do you think those files would be looked for in $(srcdir)? Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and multiple processors
On 20.02.2005, at 14:09, Sven Neumann wrote: You'd still do me a favor if you would try current CVS and told me whether it feels faster or not. It's slower, measurable and reproducible slower. As a benchmark I used a gradient fill in a 3000x3000px (68.8M) image. I get consistently times of 8s for 1 thread and between 9.2s and 9.6s for 2 threads. With a running application, after a restart -- doesn't matter. What is strange though, is that it only seems two use one CPU for both threads; maybe a stupid gthread implementation? Servus, Daniel PGP.sig Description: This is a digitally signed message part
Re: [Gimp-developer] GIMP and multiple processors
Hi, Daniel Egger [EMAIL PROTECTED] writes: It's slower, measurable and reproducible slower. As a benchmark I used a gradient fill in a 3000x3000px (68.8M) image. I get consistently times of 8s for 1 thread and between 9.2s and 9.6s for 2 threads. With a running application, after a restart -- doesn't matter. What is strange though, is that it only seems two use one CPU for both threads; maybe a stupid gthread implementation? What version did you test? What's the last ChangeLog entry? Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Builds with SRCDIR != OBJDIR broken
On 20.02.2005, at 19:29, Sven Neumann wrote: Anyone here who can fix that with some Makefile-fu? Why do you think those files would be looked for in $(srcdir)? Because the compiler complained that it couldn't find the files in $(srcdir), so what I did was copying them over one-by-one from the object directory to the source directory when the make process aborted because of it. That only happened for exactly those files mentioned; I copied there names from the history of my shell. BTW: The menus preprocessing also didn't work because of this, I had to copy over the .in files from $(srcdir) to the build tree in order for the target to build and install. It didn't bail out though, I first noticed this when starting The GIMP. Servus, Daniel PGP.sig Description: This is a digitally signed message part
Re: [Gimp-developer] GIMP and multiple processors
On 20.02.2005, at 21:55, Sven Neumann wrote: As a benchmark I used a gradient fill in a 3000x3000px (68.8M) image. I get consistently times of 8s for 1 thread and between 9.2s and 9.6s for 2 threads. With a running application, after a restart -- doesn't matter. What is strange though, is that it only seems two use one CPU for both threads; maybe a stupid gthread implementation? What version did you test? GIMP (r/w) CVS from a few hours ago (about the time when I wrote in that I'll do it but that it'll take a while...) What's the last ChangeLog entry? 2005-02-20 Sven Neumann [EMAIL PROTECTED] * app/actions/context-actions.c * app/actions/context-commands.c[ch]: added actions to control the average radius of color picker tools (bug #167765). * app/actions/tool-options-actions.c: fixed a typo in a comment. Servus, Daniel PGP.sig Description: This is a digitally signed message part
Re: [Gimp-developer] GIMP and multiple processors
Hi, Daniel Egger [EMAIL PROTECTED] writes: What is strange though, is that it only seems two use one CPU for both threads; maybe a stupid gthread implementation? Since gthread is just a very thin wrapper around pthreads, that would mean that it's a stupid pthread implementation. To me this looks like the kernel believes that it would be better to keep the threads local than to move one to the other CPU. I wonder if perhaps the kernel is right and using two CPUs would actually cause more overhead than it's worth? Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and multiple processors
On Sun, Feb 20, 2005 at 10:55:18PM +0100, Sven Neumann [EMAIL PROTECTED] wrote: mean that it's a stupid pthread implementation. To me this looks like the kernel believes that it would be better to keep the threads local than to move one to the other CPU. Linux will not keep two threads running on a single cpu if both are ready and nothing else is running, regardless of locality etc., as the kernel lacks the tools to effectively decide wether threads should stay on a cpu or not. (I mean, it's of course bad to interlave operations on a per-pixel basis instead of e.g. a per-tile basis, but the kernel will run the threads concurrently wether or not it gets slower). right and using two CPUs would actually cause more overhead than it's worth? That's quite possible, but IFF the kernel indeed keeps the two threads on a single cpu then it means that both aren't ready at the same time, e.g. due to lock contention or other things. -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and multiple processors
On 20.02.2005, at 22:55, Sven Neumann wrote: Since gthread is just a very thin wrapper around pthreads, that would mean that it's a stupid pthread implementation. To me this looks like the kernel believes that it would be better to keep the threads local than to move one to the other CPU. I wonder if perhaps the kernel is right and using two CPUs would actually cause more overhead than it's worth? Hm, it is using NPTL, e.g. if I set it to 8 threads I'll have: egger31344 2.1 14.5 219412 149008 pts/0 Sl+ 23:10 0:05 /opt/gimp-mp-test/bin/gimp-2.3 egger31344 10.8 14.5 219412 149012 pts/0 Rl+ 23:10 0:26 /opt/gimp-mp-test/bin/gimp-2.3 egger31344 11.0 14.5 219412 149012 pts/0 Rl+ 23:10 0:26 /opt/gimp-mp-test/bin/gimp-2.3 egger31344 6.5 14.5 219412 149012 pts/0 Rl+ 23:11 0:08 /opt/gimp-mp-test/bin/gimp-2.3 egger31344 5.7 14.5 219412 149012 pts/0 Rl+ 23:11 0:07 /opt/gimp-mp-test/bin/gimp-2.3 egger31344 6.8 14.5 219412 149016 pts/0 Rl+ 23:11 0:08 /opt/gimp-mp-test/bin/gimp-2.3 egger31344 6.1 14.5 219412 149016 pts/0 Rl+ 23:11 0:08 /opt/gimp-mp-test/bin/gimp-2.3 egger31344 6.8 14.5 219412 149016 pts/0 Rl+ 23:11 0:08 /opt/gimp-mp-test/bin/gimp-2.3 egger31344 6.2 14.5 219412 149016 pts/0 Rl+ 23:11 0:08 /opt/gimp-mp-test/bin/gimp-2.3 If I force it back to classical pthreads then it'll be even worse: egger31456 70.8 15.0 164232 154852 pts/0 R+ 23:32 1:53 /opt/gimp-mp-test/bin/gimp-2.3 egger31457 0.0 15.0 164232 154852 pts/0 S+ 23:32 0:00 /opt/gimp-mp-test/bin/gimp-2.3 egger31458 0.0 15.0 164232 154852 pts/0 S+ 23:32 0:00 /opt/gimp-mp-test/bin/gimp-2.3 egger31459 0.0 15.0 164232 154852 pts/0 S+ 23:32 0:00 /opt/gimp-mp-test/bin/gimp-2.3 One interesting thing here certainly is that one process (== thread) is doing all the work and the rest is doing nothing in a shape fill, while in a linear fill I'll get: egger31474 3.4 10.8 120696 111508 pts/0 S+ 23:36 0:04 /opt/gimp-mp-test/bin/gimp-2.3 egger31475 0.0 10.8 120696 111508 pts/0 S+ 23:36 0:00 /opt/gimp-mp-test/bin/gimp-2.3 egger31476 35.1 10.8 120696 111508 pts/0 S+ 23:36 0:48 /opt/gimp-mp-test/bin/gimp-2.3 egger31477 35.1 10.8 120696 111508 pts/0 S+ 23:36 0:48 /opt/gimp-mp-test/bin/gimp-2.3 However those are again running on the same CPU so rather disturbing each other then crunching away. To be continued... Servus, Daniel PGP.sig Description: This is a digitally signed message part
Re: [Gimp-developer] GIMP and multiple processors
On 20.02.2005, at 23:47, [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote: Linux will not keep two threads running on a single cpu if both are ready and nothing else is running, regardless of locality etc., as the kernel lacks the tools to effectively decide wether threads should stay on a cpu or not. Yes and no. I just figured out that the tools I were looking for are called schedutils and can be used to change the affinity settings of a process, i.e. pin it to some CPU or allow it to migrate as the kernel decides between a set of CPUs. Forcing the NPTL implementation to degrade to legacy pthreads means that one thread equals one process and thus can be controlled with taskset. Oh yes, and I just noticed that now this isn't even necessary anymore because for some reason the kernel now migrates on of the pthread processes to the other CPU automatically after a short while of processing. (I mean, it's of course bad to interlave operations on a per-pixel basis instead of e.g. a per-tile basis, but the kernel will run the threads concurrently wether or not it gets slower). Certainly. Opterons are bandwidth monsters but this doesn't mean that they'll be forgiving to stupid algorithms. That's quite possible, but IFF the kernel indeed keeps the two threads on a single cpu then it means that both aren't ready at the same time, e.g. due to lock contention or other things. I can force it to use both CPUs now, but even with 200% utilization it is 2s slower to run this stupid ubenchmark than on 1 CPU without threads. Servus, Daniel PGP.sig Description: This is a digitally signed message part
Re: [Gimp-developer] GIMP and multiple processors
Daniel Egger wrote: I can force it to use both CPUs now, but even with 200% utilization it is 2s slower to run this stupid ubenchmark than on 1 CPU without threads. Just a vague guess, but the multiprocessor GIMP pixel work scheduler might* farm alternating tiles to alternating CPUs. These are reasonably likely to have been allocated together and thus sit close together in memory, causing memory contention between CPUs. --Adam * I haven't looked at it. -- Adam D. Moss - [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
RE: [Gimp-developer] GIMP and multiple processors
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). -Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Egger Sent: Monday, 21 February 2005 9:13 AM To: [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) Cc: Sven Neumann; Developer gimp-devel Subject: Re: [Gimp-developer] GIMP and multiple processors On 20.02.2005, at 23:47, [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote: Linux will not keep two threads running on a single cpu if both are ready and nothing else is running, regardless of locality etc., as the kernel lacks the tools to effectively decide wether threads should stay on a cpu or not. Yes and no. I just figured out that the tools I were looking for are called schedutils and can be used to change the affinity settings of a process, i.e. pin it to some CPU or allow it to migrate as the kernel decides between a set of CPUs. Forcing the NPTL implementation to degrade to legacy pthreads means that one thread equals one process and thus can be controlled with taskset. Oh yes, and I just noticed that now this isn't even necessary anymore because for some reason the kernel now migrates on of the pthread processes to the other CPU automatically after a short while of processing. (I mean, it's of course bad to interlave operations on a per-pixel basis instead of e.g. a per-tile basis, but the kernel will run the threads concurrently wether or not it gets slower). Certainly. Opterons are bandwidth monsters but this doesn't mean that they'll be forgiving to stupid algorithms. That's quite possible, but IFF the kernel indeed keeps the two threads on a single cpu then it means that both aren't ready at the same time, e.g. due to lock contention or other things. I can force it to use both CPUs now, but even with 200% utilization it is 2s slower to run this stupid ubenchmark than on 1 CPU without threads. Servus, Daniel ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and multiple processors
Hi, 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. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
RE: [Gimp-developer] GIMP and multiple processors
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sven Neumann Sent: Monday, 21 February 2005 11:01 AM To: David Bonnell Cc: Gimp-developer@lists.xcf.berkeley.edu Subject: Re: [Gimp-developer] GIMP and multiple processors Hi, 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. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
