Observations about Beta 32 on quad-core Q6600:

1. Radiosity pre-trace is much slower than Beta 31. Often only 25% to 30% total
processor time is being used by POV-Ray (spread over all four cores), as if
there's a race condition or integrity hold-up, such that only one thread can
work at a time. NB: I checked that nothing else is eating CPU; the system-idle
thread gets the rest.

2. Crackle pattern with radiosity renders about 15x slower than Beta 31 (guess -
I've not benchmarked it). Perhaps the cacheing mentioned in the notes needs some
tuning, or point 1 (above) is coming into play. This note raised alarm bells
with me ("cache per thread") - see my paragraph A (below) to understand why.

3. The (radiosity?) memory management errors of Beta 29 and 30 (not in 31) have
returned: Where a significant amount of memory is used, starting the render
again produces an 'internal error' (yellow message), and aborts gracefully.
Restarting POV (with significant delay on exit while memory is freed) solves
the provlem.

A. I have found the previous Betas (31 and earlier) achieve inconsistent
radiosity samples for each SMP block, such that hard lines are visible at the
block edges - a deal-breaker in most cases. This occurs on pattern-based
normals, and implicit functions with high gradient. Increasing the 'radiosity
end pretrace' reduces this problem a bit, but I can't get away from the fact
that each SMP block uses different lighting data. I'm testing this
(incidentally) on a scene at the moment, so will be able to report more soon.

I'll be able to report with more authority on the above with more testing, but
thought to post as-is now, in case it was of use, or already known.

-- JV.

Post a reply to this message