Am 13.08.2015 um 15:57 schrieb Mike Horvath:
> On 8/13/2015 6:43 AM, clipka wrote:
>> The Windows version already displays its current memory usage in the
>> status bar; and the render statistics output includes the peak memory
>> usage during the render (IIRC the Unix version does that as well).
>>
>
> Eventually Windows will step in and terminate the program,

That doesn't match my experience - usually the Reset button needs to 
step in and terminate the entire OS.

> at which time
> any statistics are lost unless POVray stores them somewhere on disk.

What would you want with such a log on disk? All it'll tell you is that 
the system went bonkers at X bytes of memory usage - but I don't need a 
log to tell you that X = your physical memory size.

Post a reply to this message

Am 13.08.2015 um 15:58 schrieb Mike Horvath:

> I just increased the size of the swap file to 32GB and that still wasn't
> enough. Time to give up.

You'd need to increase physical memory size, not swap file size.

Post a reply to this message

Am 14.08.2015 um 04:07 schrieb Bald Eagle:
> What about using an SD card or similar storage device for "memory", such as with
> "Ready Boost"
>
http://windows.microsoft.com/en-us/windows/using-memory-storage-device-speed-computer#1TC=windows-7
> or "eBoostr"
>
> coupled with:
>
>
http://arstechnica.com/gadgets/2015/08/samsung-unveils-2-5-inch-16tb-ssd-the-worlds-largest-hard-drive/
>
> http://bgr.com/2015/07/28/intel-micron-3d-xpoint-ram-memory-technology/
>
> ?

SSD is pretty damn fast compared to HDD, but compared to physical main 
memory it's still sluggishly slow. It also doesn't help at all that to 
access even a single byte of swap memory the operating system needs to 
retrieve the entire corresponding page (4 kB) from the storage medium to 
main memory.

As far as POV-Ray is concerned, the only substitute for genuine physical 
main memory is genuine physical main memory.

Post a reply to this message

On 8/14/2015 2:56 AM, scott wrote:
> On 13/08/2015 18:39, Mike Horvath wrote:
>> On 8/13/2015 10:21 AM, scott wrote:
>>>> The Lego town I am working on takes a lot of RAM when you turn the
>>>> little top studs on.
>>>
>>> How many top studs do you have in total? You might be able to get away
>>> with only turning them on for the visible ones in the foreground. Once
>>> the studs get to be less than a couple of pixels big you probably won't
>>> notice that they're gone (especially with a little bit of focal blur).
>>>
>>
>> It's an orthographic render, so all studs are the same size everywhere.
>
> How many in total?
>

Over two million.

Post a reply to this message

On 8/14/2015 11:44 PM, clipka wrote:
> What would you want with such a log on disk? All it'll tell you is that
> the system went bonkers at X bytes of memory usage - but I don't need a
> log to tell you that X = your physical memory size.
>

Oh, I thought POV-Ray uses virtual memory when physical memory runs out. 
Never mind then.


Mike

Post a reply to this message

On 8/14/2015 2:56 AM, scott wrote:
> On 13/08/2015 18:39, Mike Horvath wrote:
>> On 8/13/2015 10:21 AM, scott wrote:
>>>> The Lego town I am working on takes a lot of RAM when you turn the
>>>> little top studs on.
>>>
>>> How many top studs do you have in total? You might be able to get away
>>> with only turning them on for the visible ones in the foreground. Once
>>> the studs get to be less than a couple of pixels big you probably won't
>>> notice that they're gone (especially with a little bit of focal blur).
>>>
>>
>> It's an orthographic render, so all studs are the same size everywhere.
>
> How many in total?
>

Over two million.

I forgot to add the important fact that the studs are not the only 
things being turned on/off. In fact, most of the internals of each part 
such as the inner cavity and tubes are also being enabled/disabled.

So there's more going on than just the little studs.


Mike

Post a reply to this message

Am 15.08.2015 um 06:38 schrieb Mike Horvath:
> On 8/14/2015 11:44 PM, clipka wrote:
>> What would you want with such a log on disk? All it'll tell you is that
>> the system went bonkers at X bytes of memory usage - but I don't need a
>> log to tell you that X = your physical memory size.
>>
>
> Oh, I thought POV-Ray uses virtual memory when physical memory runs out.
> Never mind then.

Well, /unfortunately/ it does.

POV-Ray is a rather special beast with regards to system performance 
requirements. In contrast to most applications it really needs to access 
much of its data pretty frequently, and its render tasks don't do any 
file i/o at all, so it keeps the operating system busy juggling virtual 
memory back and forth.


With that in mind, I wonder whether /reducing/ the number of render 
threads might help keep the system somewhat stable in such a situation.

Post a reply to this message

On 8/15/2015 1:00 AM, clipka wrote:
> Well, /unfortunately/ it does.
>
> POV-Ray is a rather special beast with regards to system performance
> requirements. In contrast to most applications it really needs to access
> much of its data pretty frequently, and its render tasks don't do any
> file i/o at all, so it keeps the operating system busy juggling virtual
> memory back and forth.
>
>
> With that in mind, I wonder whether /reducing/ the number of render
> threads might help keep the system somewhat stable in such a situation.
>

I would be willing to sacrifice render speed for stability. In my case 
the parsing is what uses all the resources, and rendering only takes a 
few minutes even at 8192x8192px. As an option of course.


Mike

Post a reply to this message

Am 15.08.2015 um 19:54 schrieb Mike Horvath:
> On 8/15/2015 1:00 AM, clipka wrote:
>> Well, /unfortunately/ it does.
>>
>> POV-Ray is a rather special beast with regards to system performance
>> requirements. In contrast to most applications it really needs to access
>> much of its data pretty frequently, and its render tasks don't do any
>> file i/o at all, so it keeps the operating system busy juggling virtual
>> memory back and forth.
>>
>>
>> With that in mind, I wonder whether /reducing/ the number of render
>> threads might help keep the system somewhat stable in such a situation.
>>
>
> I would be willing to sacrifice render speed for stability. In my case
> the parsing is what uses all the resources, and rendering only takes a
> few minutes even at 8192x8192px. As an option of course.

In that case use only one single render thread ("+wt1").


Also, if you're using radiosity, that is also something that eats up 
memory that you might get away without, if you use UberPOV and its 
"no_cache" radiosity option; if you use this, UberPOV will not store 
/any/ radiosity-related data, which obviously increases render time but 
saves a lot of memory (plus it also trades various types of artifacts 
for random noise, wich can be reduced easily by simply throwing more 
render time at it in "+am3" mode).

Post a reply to this message

On 8/16/2015 3:47 AM, clipka wrote:
> Am 15.08.2015 um 19:54 schrieb Mike Horvath:
>> I would be willing to sacrifice render speed for stability. In my case
>> the parsing is what uses all the resources, and rendering only takes a
>> few minutes even at 8192x8192px. As an option of course.
>
> In that case use only one single render thread ("+wt1").
>

I turned on the +wt1 switch and the render crashed outright. I uploaded 
the dump to wherever they get sent to.

>
> Also, if you're using radiosity, that is also something that eats up
> memory that you might get away without, if you use UberPOV and its
> "no_cache" radiosity option; if you use this, UberPOV will not store
> /any/ radiosity-related data, which obviously increases render time but
> saves a lot of memory (plus it also trades various types of artifacts
> for random noise, wich can be reduced easily by simply throwing more
> render time at it in "+am3" mode).
>

Radiosity is turned off.


Mike

Post a reply to this message