Certain types of image processing routines are almost trivial to break into
SMP threads under NT, especially if you can get all the performance from
just partitioning the image.  It can be done using only a thread control
structure, ResumeThread, SuspendThread, and Sleep functions and wrappers
around the needed image processing routines.  Alternating scanlines is
better because it minimizes paging at the various cache levels.

This doesn't give a very general solution but works great under NT and the
code can run fine in Win98.  It only gets messy when the multiple threads
have to access the same data, that is, if the changes made by one thread
depend on the changes made by the other thread.  Then the synchronization to
avoid exceptions destroys the performance or exception handling itself
becomes too complicated to manage.  If the core routines can be individually
treated, that's where all the performance gain is anyway.

--
Tim Hutcheson
w4l### [at] bellsouthnet


Ron Parker <par### [at] fwicom> wrote in message
news:374aa7a5.0@news.povray.org...
> On Tue, 25 May 1999 14:30:43 +0200 (CDT), Jan Danielsson wrote:
> >How should a multithreaded povray work?
> >
> >I guess the user specifies how many threads he/she wants, then what?
> >
> >Should the threads render lines, or should it devide to picture in to
> >'imageheight devided by threads' blocks and render them?
>
> Ignoring for a moment how hard any multithreaded design will be to
> implement in practice, I think a thread should always just do whichever
> scanline is next when it gets ready to go.  For one thing, this will
> help minimize the amount of rendered information that is hanging
> around in memory without having been written to the file.  For another,
> it will do a more effective job of balancing the load between the
> threads.  Skyvase, for example, spends most of its time in the bottom
> half of the image.
>
> You could, of course, run a low-resolution test render first and
> assign blocks of the image based on the histogram results.
>
> Okay, now let's stop ignoring how hard a multithreaded design is.  Can
> I ask all of you "we need SMP so we need threads" people what's wrong
> with plain ol' fork?  Yeah, Winblows doesn't support fork natively,
> but that seems like something Mickeysoft should fix.  Or just install
> a real OS on your fancy SMP machine.

Post a reply to this message