RL is keeping me quite busy these days, but I've been able to make some progress
on the radiosity code nonetheless:

- I seem to be getting closer to the causes of the slowdown in the beta.30-rad1,
so I hope soon to be able to sort that one out.

- I've been able to come up with a solution that allows for 100% reproducable
shots with multiprocessing, at a performance cost of only 10%-20%.

The basic idea is to re-use samples only if they were taken during a previous
pretrace step, or for the same "tile". However, with higher recursion depths
this would almost certainly lead to loads of duplicate samples taken during the
first pretrace step, so I modified this a bit.

During the first pretrace step, I force all the tiles to be rendered one at a
time in a default order, so I can safely allow re-use of any samples taken
during the same pretrace step. Due to the typically low resolution this is
still acceptably fast to do single-threaded, and already gives a decent
coverage at higher recursion depths without any duplicates.

During the second, pretrace step, I split up the tiles in two sets, each of
which again is to be rendered one at a time in a default order, so samples
taken during the same pretrace step can still safely be re-used within the same
set of tiles. Typically, resolution will still be low enough to render
reasonably fast with reduced thread count; dupes at higher recursion depths are
reduced both by the samples already gathered during first pretrace step as well
as the still limited thread count, so some dupes may be gathered, but no
triples or quadruples.

The approach can be continued during the whole pretrace, repeatedly splitting up
the tiles into ever more sets.

Note that thread count can actually be lower than the number of tile set. Tiles
can be safely assigned to any thread, as long as only one tile per set is being
processed at any time, so the approach works with any arbitrary thread count
lower or equal to the number of tile sets.

Post a reply to this message