Chen Yang wrote:
> hi, all:
>   I'm a novice in ray tracing. I'm currently parallelizing povray using
> threads, but I have problem in making it generate the same result as the
> sequential version, I have spent some time in finding the problem

There's more than one problem :)

> What's the random number usage in povray? I found it is used in supersample/sample
distribution.

It's used all over the place.  I solved the threaded-randomness problem 
by making the "random" functionality instanced, rather than global.

Using instances rather than globals is the key to making POV-Ray 
thread-safe.  However, as Thorsten indicated, this is no small 
undertaking.  Many algorithms in POV-Ray need adjustments to be made 
thread-safe.

To your specific question, the anti-aliasing system in POV-Ray is very 
anti-threads.  I ended up rewriting it.

The technique I'm using is to make two passes on the image.  The first 
pass is one ray through the middle of the every pixel, storing the raw 
result in memory.  The second pass compares the in-memory pixels to 
their 8 surrounding neighbors and then throws a user-defined amount of 
additional rays in an even pattern within the pixel, averaging the results.

The first-to-second-pass transition is the only time the threads have to 
synchronize.  During the rendering, they each work on their own pixel 
and use thread-safe incrementing on a global counter to divide the 
workload.  It works flawlessly--I've tested it on 4-way Xeon systems 
with no artifacts or glitches at all (not to mention that it was very 
fast :)

The main drawback to this technique is that it takes 20 bytes of memory 
per pixel to hold the buffer for the first pass.  10 years ago, that 
problem would have made it unfeasable, but on modern hardware it's not bad.

If one was willing to give up the precision of floating point color 
channels, that could be reduced to 4 bytes per pixel by using RGBA 
values stored in 8-bit integers.

The result is not quite as good as either of the original algorithms, 
but it's not bad at all--most people wouldn't notice.  Some further work 
could resolve the remaining quality differences, if I had time to spend 
on it.

>      Also, I have one question, how do you graphic guys consider whether the
> generated result is correct or not? Do you permit certain difference in
> pixels?

Mapping infinitely-precise objects onto square pixels is automatically 
"incorrect".  In the graphics world, we strive for the best possible 
approximation.

-Ryan

Post a reply to this message