Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> Just an FYI to the folks who are interested: Christoph's radiosity fixes
> have been integrated and see to work very well. A hearty 'thanks' to him
> for this! I intend to do a release in the next day or two that incorporates
> the new code.

You're welcome! It's all just pure selfishness anyway :)

> On my system (8 cores), cornell.pov at 1280x1024 AA 0.3 renders in 20
> seconds with a speedup ratio of about 7x. I haven't looked into what might
> be chewing up the rest of the CPU time, other than to note that the cores
> aren't quite 100% pegged in the first five or so seconds of the render. (I
> am guessing it may be related to the early sampling and octree code but

Some things that may come into play here:

- The pre-render is done in multiple passes again, and after each pass the
system waits for all threads to finish (this will get some importance when
heading for that 100% reproducability thing) before starting the next pass;
this is *one* reason why the CPU utilization doesn't reach 100% during the
first seconds. This effect is strongest of course in images that render very
quickly, but will probably not be much of an issue for renders that take long
anyway. (A potential idea for optimization here would be to measure the (CPU)
time spent on a block during each pass, and do the most "expensive" ones first
during the next pass.)

- The first seconds of the pre-render sees a very high ratio of new samples
being taken per ray shot, with each new sample requiring the radiosity cache to
be locked for a brief moment, making it more likely for a thread having to wait
for another one to release its lock. In addition, and probably more
importantly, much of the cache's octree structure used to organize the samples
still has to be "grown" in this phase, again requiring a lock each time
additional nodes are added; these locks need to be maintained for a much longer
duration than for the mere adding of samples. These are additional reasons for
the incomplete utilization.

- The splotchy artifacts seen in 3.6 radiosity were due to a flawed design that
"cut short" some sample rays; with the flaws fixed, these rays are traced
further than before, increasing rendering time accordingly. (This shouldn't
play a role on cornell.pov though.) In addition, the fixes required passing
additional data through the render engine, thereby increasing general rendering
overhead a bit.

- With increasing radiosity recursion depth, POV-Ray reduces some quality
parameters. I modified the corresponding rules a bit in favor of quality, which
of course comes at a cost of time.

> either way I'm happy enough with it just as it is:)

Glad to hear that. I hope the beta testers will be as well. Me, however, I'm not
yet ;) I'm still trying to get some speedup for high-quality shots, using an
adaptive pretrace approach. Still encountering some obstacles though.

Post a reply to this message