|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |