Interesting...and I see the problem now.  tnx

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


Ron Parker <par### [at] fwicom> wrote in message
news:374b1d23.0@news.povray.org...
> On Tue, 25 May 1999 16:24:14 -0500, Tim Hutcheson wrote:
> >> Fix all of the global variables and other weirdness (like variable
reuse)
> >> and then it would be a fairly easy task.
> >
> >Agreed.
> >
> >But usually you can find some low level which sacrifices generality and
> >elegance (but avoids the globals problem) in critical routines that can
be
> >threaded to yield 90 percent of the performance improvement without doing
a
> >full-up SMP design.  Kind of a thread-lite approach.  I have had some
> >surprising results with a little effort on routines that I thought were
> >impossible to multi-thread, like fuzzy c-means clustering (FCM).  That
> >involved splitting the image work into two threads, synchronizing
completion
> >and then doing a final pass to merge the results.  But it essentially
> >doubled the performance with two processors.
> >
> >I have the source installed, what's a good candidate routine?
>
> That's the problem, there is no good candidate routine.  The best way to
> parallelize POV is by tracing different rays in different threads, but
> it's the code that traces a ray that isn't threadsafe, and the problems
> are spread throughout the code.  Somewhere in excess of 90% of the code
> is called from within the "trace a ray" function at one time or another.
>
> As an example of some things that aren't thread safe:
>
> o The crackle pattern generates an array of nearby centers to determine
>   where it is within the voronoi diagram.  This array is a global
>   variable and is cached from use to use.  If two threads are rendering
>   a crackle pattern at the same time, one could refill this array while
>   the other is trying to calculate with it.  If you serialize access to
>   it, you may end up serializing some scenes entirely.  If you eliminate
>   the caching, you will slow down the trace considerably.
>
> o The area light code saves off the center of the light source into a
>   local variable, "fiddles" with it during the calculations, then
>   restores it when it's done.  Hopefully it's obvious why this isn't
>   threadsafe.
>
> o The crackle pattern saves the current RNG seed before filling its array,
>   then restores it afterward.  While filling its array, it depends on the
>   sequence of "random" numbers being reproducible.  The black hole warp
>   is similarly dependent.  If one thread came in and grabbed a random
>   number while another thread was inside this code, the image would be
>   ruined in a very obvious manner.
>
> o Some code apparently depends on the RNG being repeatable, as one of the
>   changes in a recent update was the saving and restoring of the RNG seed
>   mentioned in the previous point.  If two or more threads are using the
>   same RNG, it will not be repeatable.
>
> o The radiosity code saves some global settings, modifies them, and then
>   restores them later.
>
> o Determine_Apparent_Colour - a very important, central function - saves
>   the texture, weight, and light lists before doing whatever it does, then
>   restores them afterward.

Post a reply to this message