Hi!
I'm using one of my WIP (Babel tower) to compare the speed of 3.6.1a vs 3.7
beta5a vs 3.7 beta6. In this scene, the ground is an isosurface.

At 1024x768, no AA, no radiosity, 1 thread when applicable, i get the
following CPU time used (in seconds):

    3.6.1a           3.7 beta5a        3.7 beta6
(the scene as is)
    316.72         468.94(+48%)     469.45(+48%)
(with a point_light instead of an area_light)
     95.56         140.88(+47%)     138.33(+45%)
(with a plane instead of an isosurface)
     26.00          29.23(+12%)      27.02(+4%)

Clearly the isosurface is causing most of the overhead. Sticking with a
point light for now, i tried the following, knowing that max_gradient was
around 10.
(with evaluate 5.48, 1.29, 0.8)
     95.56         140.88(+47%)     138.33(+45%)
(with evaluate 4, 1.37, 0.2)
     86.81          99.92(+15%)      94.50(+9%)
(with a fixed max_gradient of 9.5)
    115.53         123.33(+7%)      119.97(+4%)

I tend to jump to the conclusion that in 3.6.1a using evaluate instead of a
fixed max_gradient leads to faster renders, more or less so depending on
the parameters (17% or 25% faster in the case above), whereas in the betas,
evaluate with nonoptimal parameters can lead to definitely slower renders
(approx. 15% slower above).

JYR

Post a reply to this message

JYR wrote:
> 
> I tend to jump to the conclusion that in 3.6.1a using evaluate instead of a
> fixed max_gradient leads to faster renders, more or less so depending on
> the parameters (17% or 25% faster in the case above), whereas in the betas,
> evaluate with nonoptimal parameters can lead to definitely slower renders
> (approx. 15% slower above).

evaluate in isosurfaces is one of the features that will inevitably lead 
to different results (and especially also different performace) in a 
multithreaded render.

Note although there is no 'correct' way to handle this the most 
reasonable would probably be to have every render thread maintain its 
own evaluate parameters.  But in the end using 'evaluate' makes most 
sense in a single threaded render.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 03 May. 2005 _____./\/^>_*_<^\/\.______

Post a reply to this message

Christoph Hormann <chr### [at] gmxde> wrote:
> evaluate in isosurfaces is one of the features that will inevitably lead
> to different results (and especially also different performace) in a
> multithreaded render.
>
> Note although there is no 'correct' way to handle this the most
> reasonable would probably be to have every render thread maintain its
> own evaluate parameters.  But in the end using 'evaluate' makes most
> sense in a single threaded render.

Hi Christoph, thanks for the quick answer. Unfortunately i can't seem to
fully understand it. Maybe i'm missing some background on how the
isosurface solving works in POV.

I am in the impression that, as it solves the intersection of rays with an
isosurface all through the picture, POV constantly adjusted max_gradient to
match the found gradients:
- starting with P0 as a first estimate (for the 1st ray/isosurface
intersection to be computed, presumably),
- rising max_gradient each time it happens to be lower than the computed
gradient to avoid holes in the isosurface,
- lowering max_gradient when it happens to be way larger than the computed
gradients in order to speed things up.
Then, i can understand that for a multithreaded render, each thread can have
its own set of parameters. After all, one thread can happen to compute
intersections with the stiffest parts of the isosurface while another
encounters only smoother parts. And i'm willing to agree that this would be
more reasonable than having all threads struggling to constantly overwrite
each other's evaluate parameters.

But, the render times i posted earlier were obtained with the /threads 1
switch. I now tried with 2, 16, 128 threads and the results are quite alike
(not surprisingly). Are you implying that each block of 1024 pixels is
actually a new picture on its own and POV resets the evaluate parameters
before each? Then the yet-to-be-implemented option to choose block size
would be very useful, i guess...



JYR
-----------------------------------------------------
Windows XP HomeEdition//AMD Athlon XP 2800+1 MB RAM

Post a reply to this message

JYR <jyr### [at] hotmailcom> wrote:
> Are you implying that each block of 1024 pixels is
> actually a new picture on its own and POV resets the evaluate parameters
> before each?

  If some data is modified during rendering (ie. it's not read-only),
sharing it between threads introduces problems. The 3.7 code tries to
avoid this as far as possible: Most of the scene data, once parsed and
created, is read-only, ie. is not modified during rendering (with some
parts of the code it actually required some rewriting for this to be so
because they needlessly used eg. temporary buffers which were modified
during rendering).

  If there's no way around it, ie. some feature simply must modify its
data during rendering, then the next best choice is to allocate the
data separately for each thread. In practice this means, indeed, that
each thread is basically its own separate render (even though they share
most of the read-only scene data in memory, thus saving great amounts
of it).

  I don't know what is the case specifically with isosurface evaluation,
though.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> If some data is modified during rendering (ie. it's not read-only),
> sharing it between threads introduces problems. The 3.7 code tries to
> avoid this as far as possible: Most of the scene data, once parsed and
> created, is read-only, ie. is not modified during rendering (with some
> parts of the code it actually required some rewriting for this to be so
> because they needlessly used eg. temporary buffers which were modified
> during rendering).

I see... and i guess it points out the very cause for 2 bugs still present
in 3.7.beta6, namely web.429167334ebdfea56a3607400@news.povray.org
(isosurface contained by a sphere randomly mangling the balance of the
scene) and web.428f943986c60abc6a3607400@news.povray.org (black opaque
sphere carved out of a semi transparent box giving artifacts on the back
side of the box). In both cases it looks like some data that is supposed to
be read-only is actually modified during rendering - especially in the first
case, the first square or first 2 squares to actually contain the
isosurface are ok, but the balance of the scene doesn't make sense.

JYR
---------------------------------------------------
Windows XP HomeEdition//AMD Athlon XP 2800+1 MB RAM

Post a reply to this message