I farted around with my own SMP raytracer and, while RT is theoretically
easy to parallelize, in practice its much harder (of course, maybe I'm too
dense to figure out the right way). Avoiding malloc is very important to
rendering speed so you need pools of pre-alloc'd temporaries. Thread-safing
these pools is fairly costly. The best solution I found is to use MSVC's TLS
storage since it only uses an FS: instruction to access TLS data. This is
non-portable in the extreme so its out for POVRay.

The # of threads should be automatically determined by the # of processors
installed.

The best answer is for a thread to start rendering the next free line. The
problems start when antialiasing. Again I my be dense but in my aa code I
reuse the topmost subpixels in a line while subdividing to avoid
recalculating the same ray. This creates a linkage between lines which
requires thread-safing and/or buffering. Since the reason for SMP is a speed
advantage, this thread-safing gets in the way.

Mutithreaded initialization is another, less important area. Some time is
spent crunching heightfields and other objects so that tracing is faster.
Photon mapping would benefit the most here. This would be a low priority
item.

There are other issues like random number generation that can affect output
images between single and multithreaded implementations. This would be last
on my list of issues, though.

Mike


Jan Danielsson <Jan### [at] falunmailteliacom> wrote in message
news:wnaqnavryffbasnyhaznvygryvnpbz.fcawr70.pminews@news.povray.org...
> 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?
>
>
>  /j
>
>
>

Post a reply to this message