"MessyBlob" <nomail@nomail> wrote:
> 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.

I find this hard to believe, as radiosity code has not changed from beta 31 to
32, except for some performance counters that are kept local to each thread.

Are you sure you're not comparing to an earlier version's performance?

(In case your scene should happen to contain only a single, small,
"radiosity-intensive" detail, such effects might occur when POV is waiting for
the last cell to complete at the end of each pretrace step.)

Furthermore, I have never seen such an effect in the radiosity code benchmarks I
run on a regular basis - although admittedly those run on Linux, not Windows, so
there *may* be a Windows specific issue; still, there's no reason to expect
different behavior between beta.31 and beta.32.

Are you sure this is not some other issue, which just happens to be "multiplied"
by radiosity? Is it just one particular scene, or a kind of invariant? Can you
boil it down to a "minimal" scene showing the slowdown?


> 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.

Both of these are very unlikely to be radiosity-related, as no changes have been
made to radiosity except for those performance counters already mentioned. So
the best bet (for both, actually) would be problems with the crackle cache.


> 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.

The effect you see is simply an inevitability if your pretrace is poorly tuned
(or you have "always_sample" set to "on", which unfortunately is the default);
every(!) sample taken during final render *will* produce an artifact; it's just
a matter of the pixels rendering order to determine how it manifests:
Horizontally "smeared" blotches are telltale signs of a
horizontal-line-oriented approach (like in POV 3.6, and within each SMP box in
POV 3.7), while prominent brightness differences between SMP blocks are -
obviously - the result of a block-oriented aproach.

The basic problem occurs when during the final render a pixel *needs* an
additional sample, while pixels in the vicinity *could* make use of that
additional sample but by themselves wouldn't call for it. Unfortunately, on
average half of these will have been rendered already by the time the new
sample is found to be inevitable and is therefore computed. The pixels not yet
rendered will pick up that sample, while those already rendered will not be
able to do so.

As you can see, there is no SMP involved so far. It's just the block-oriented
pixel rendering order you see, nothing more.

A good rule of thumb for pretrace tuning is that at least half the samples
should be gathered during pretrace already; unless you're using exotic
settings, this is usually sufficient to keep the artifacts below visibility.
Provided you switch "always_sample" off, that is.

Make sure to use "low_error_factor" and "nearest_count" - they're the chief
weapons to make sure pretrace gives a good sample coverage for the main render.

Post a reply to this message