The majority of these 'cached' variables could be put in the thread's scope
instead of the global scope.  But I had to go and introduce even more global
variables in my photon mapping stuff (so that I could pass values around
without adding more parameters to the existing functions).  Of course, you'd
have to find all of these, but that's not impossible.  In fact, I'm going to
label the ones I make in future releases of the photon patch with the
comment:
  /* not thread safe */
so if you search for that, you'll find them.

-Nathan


Ron Parker wrote:
> 
> 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