I have a scene that causes Beta 39 to behave strangely. When the render 

released and pvengine.exe is still using about 48% of one core. Then on 
the next render I get an unknown internal error.

application has requested the Runtime to terminate in an unusual way.

For my Acer laptop, Core 2 Duo  2.2 GHz, 3 GB ram:
Parser Statistics

Finite Objects:      1333134
Infinite Objects:          3
Light Sources:             1
Total:               1333138

Parser Time
   Parse Time:       0 hours 21 minutes 13 seconds (1273.422 seconds) 
using 1 thread(s) with 1155.156 CPU-seconds total
   Bounding Time:    0 hours  5 minutes 42 seconds (342.612 seconds) 
using 1 thread(s) with 334.060 CPU-seconds total

I can post the scene if required

-- 

Best Regards,
	Stephen

Post a reply to this message

Am 30.10.2010 14:13, schrieb Stephen:
> I have a scene that causes Beta 39 to behave strangely. When the render

> released and pvengine.exe is still using about 48% of one core. Then on
> the next render I get an unknown internal error.

> application has requested the Runtime to terminate in an unusual way.

There are some situations where the render engine takes excessively long 
to clean up, but from all I've seen so far it always finishes 
eventually. IIRC the reaction you describe is exactly what you get in 
such cases if you get impatient.

> I can post the scene if required

That might help.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> There are some situations where the render engine takes excessively long
> to clean up, but from all I've seen so far it always finishes
> eventually.

Is it worth getting hands dirty with the memory manager interface, to start new
renders using a new 'root' (or handle list - I've no seen what's used) for
memory allocation. That way, the clean-up can be happening in the background for
the old render, while the new render is starting.

This would work in the majority of cases where there is no pressure on the
system to swap out memory.

Post a reply to this message

On 30/10/2010 1:30 PM, clipka wrote:
> Am 30.10.2010 14:13, schrieb Stephen:
>> I have a scene that causes Beta 39 to behave strangely. When the render

>> released and pvengine.exe is still using about 48% of one core. Then on
>> the next render I get an unknown internal error.

>> application has requested the Runtime to terminate in an unusual way.
>
> There are some situations where the render engine takes excessively long
> to clean up, but from all I've seen so far it always finishes
> eventually. IIRC the reaction you describe is exactly what you get in
> such cases if you get impatient.
>

That could be the case, I suppose waiting 15 minutes after PovRay 
reported the render to be finished is a tad impatient.

Using  32 bit version of Beta 39 PovRay still holds on to the memory and 
raises an exception when exiting the program. The 64 bit version works 
as expected.

>> I can post the scene if required
>
> That might help.

I've posted it in p.b-t.b and sent a short dump.

Thanks to MessyBlob for bumping this thread.

-- 
Regards
     Stephen

Post a reply to this message

Am 20.11.2010 17:02, schrieb Stephen:

>> There are some situations where the render engine takes excessively long
>> to clean up, but from all I've seen so far it always finishes
>> eventually. IIRC the reaction you describe is exactly what you get in
>> such cases if you get impatient.
>>
>
> That could be the case, I suppose waiting 15 minutes after PovRay
> reported the render to be finished is a tad impatient.

I'd say, waiting 15 minutes after POV-Ray reported the render to be 
finished is a sign of /pathological patience/, and any sane person would 
have lost theirs entirely by then ;-)

Post a reply to this message

On 21/11/2010 3:26 AM, clipka wrote:
>
> I'd say, waiting 15 minutes after POV-Ray reported the render to be
> finished is a sign of /pathological patience/, and any sane person would
> have lost theirs entirely by then ;-)

:-D

-- 
Regards
     Stephen

Post a reply to this message

On 21/11/2010 03:02, Stephen wrote:
> I've posted it in p.b-t.b and sent a short dump.

I've had a look at this. Part of the issue is that it hits the internal
link to frame stage with one top-level union that contains 2,116,139
sub-objects, spread amongst many other sub-unions (961,880 children at the
second level, for example). POV-Ray will flatten these out if possible and
then destroy the containing union; this causes additional memory ops (we
might like to look at making this more efficient) but I haven't evaluated
how much difference it makes vs not doing so.

During shut-down of the Windows version, if the de-allocation of memory
blocks takes more than five seconds, the worker thread is forcibly shut
down. However, this was not being handled properly within that code and
consequently Windows would issue an 'unusual termination' message, or the
program would just crash. That should now be fixed.

As for why it's sitting using CPU for a long time after the render is
finished, or crashing on another render attempt: I can't say exactly what's
going on there as I didn't see that behavior when testing.

Also, in response to your original query as to why the memory is not freed
after the render: the internal architecture of POV-Ray 3.7 separates the
scene from the render; i.e. the parsing of the scene is totally separate
from the render, and technically the same parsed scene data may be used in
multiple renders (either simultaneously or sequentially). This isn't
implemented yet (i.e. you can't actually do it) but that's more a UI
limitation than anything else. Put another way, the parsed scene data (and
hence all the memory it uses) stays around after a render until it's
explicitly destroyed, which doesn't happen until a new render starts or the
program exits.

-- Chris

Post a reply to this message

On 20/11/2010 22:51, MessyBlob wrote:
> Is it worth getting hands dirty with the memory manager interface, to start new
> renders using a new 'root' (or handle list - I've no seen what's used) for
> memory allocation. That way, the clean-up can be happening in the background for
> the old render, while the new render is starting.

We could move the point where the scene data is destroyed. Currently it's
kept around until a new render is started (see my other recent reply in
this thread as to why). Until such time as we do support re-use of the
scene, though, there's probably no harm in releasing it early. I'll have to
see what other implications that might have though.

-- Chris

Post a reply to this message

On 22/11/2010 4:47 AM, Chris Cason wrote:
> On 21/11/2010 03:02, Stephen wrote:
>> I've posted it in p.b-t.b and sent a short dump.
>
> I've had a look at this. Part of the issue is that it hits the internal
> link to frame stage with one top-level union that contains 2,116,139
> sub-objects, spread amongst many other sub-unions (961,880 children at the
> second level, for example).

You try modelling the Sydney "coat hanger" with less. :-P
The Forth Rail Bridge is smaller.


> During shut-down of the Windows version, if the de-allocation of memory
> blocks takes more than five seconds, the worker thread is forcibly shut
> down. However, this was not being handled properly within that code and
> consequently Windows would issue an 'unusual termination' message, or the
> program would just crash. That should now be fixed.
>

That's good :-)

> As for why it's sitting using CPU for a long time after the render is
> finished, or crashing on another render attempt: I can't say exactly what's
> going on there as I didn't see that behavior when testing.
>

Did I say that? I meant to say that PovRay held onto its memory.
Try running a two frame animation. On the second frame I got an "unknown 
internal error".

> Also, in response to your original query as to why the memory is not freed
> after the render: the internal architecture of POV-Ray 3.7 separates the
> scene from the render; i.e. the parsing of the scene is totally separate
> from the render, and technically the same parsed scene data may be used in
> multiple renders (either simultaneously or sequentially).

This has been a feature request for years. :-D

> This isn't
> implemented yet (i.e. you can't actually do it) but that's more a UI
> limitation than anything else. Put another way, the parsed scene data (and
> hence all the memory it uses) stays around after a render until it's
> explicitly destroyed, which doesn't happen until a new render starts or the
> program exits.
>



-- 
Regards
     Stephen

Post a reply to this message