Christian Froeschlin <chr### [at] chrfrde> wrote:
> An alternative approach would be to simply give each thread its
> own cache. The threads will redo work done by other threads but it
> may actually be less costly than locking stuff. It will be simple
> to implement and faster than single-threaded pretrace unless
> building the cache takes 100% of pretrace time. It removes
> race conditions at least for individual pixels.

Yup, thought of it too.

> Unfortunately, the resulting image would then still depend
> on the number of threads which were actually used, so anyone
> who whished to exactly reproduce a scene would have to use
> the same thread count.

Not necessarily so. If the image is *always* divided into the same number of
blocks, *always* using separate trees for any two blocks even if they are
processed by the same thread, and *always* merging the trees in the same order,
then we do have 100% reproducibility regardless of thread count.

If in addition we have each thread render only one pretrace pass at a time, then
consolidate all collected samples into one tree before proceeding with the next
pretrace pass, we also reduce the number of surplus samples taken.

In the first pretrace pass, the probability is quite low that two tasks need
samples so close together that one of them would actually be not needed.

In the second pretrace pass however, the first pass will already have generated
quite a number of "deeper-bounce" samples to start with.


This brings me to some *GOOD* idea... hey, thanks for the inspiration!

(I'll go into detail in a separat thread... this one has accumulated too much
"spin-offs" for my taste.)

Post a reply to this message