 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
My computer just locked up due to lack of memory. I got a black screen
and had to reboot. Is this supposed to happen? Shouldn't POVray be
switching over to virtual memory?
Windows 7 Pro x64
8GB RAM
POV-ray 3.7.0.msvc10.win32
Not sure how much swap memory got used up during the render.
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 13/08/2015 07:04, Mike Horvath a écrit :
> My computer just locked up due to lack of memory. I got a black screen
> and had to reboot. Is this supposed to happen? Shouldn't POVray be
> switching over to virtual memory?
The system is in charge of virtual memory. Povray is just an application
with sometime huge need of memory.
>
> Windows 7 Pro x64
> 8GB RAM
> POV-ray 3.7.0.msvc10.win32
>
> Not sure how much swap memory got used up during the render.
Next time, open the task manager before starting the render, to see how
it goes.
The handling of swap (virtual memory) by most OS can be such a slow down
with random access that it turns super-speedy processor into very slow
snail. Some operating system do not even have protected special pages of
memory for themselves (excepted the swap routine... if you swap that
part of memory on disk, you're dead soon), and that might include the
data to draw the display: so, when refreshing the picture, such as when
moving the mouse and asking a redraw to all applications when exiting
screen-blank-economy mode (or other), it would need to access a lot of
pages while an active process is still asking a hell lot of other
pages... so refreshing the screen would take hours... hence your black
screen.
Usually swap is used with huge documents (photos or movie, or even
texts) whose only a tiny part need to be access at once, and the
distribution of the data is such that the accessed part for the current
task is usually a small set of continuous portions of the memory, so
putting the remainder of the memory on the disk is invisible to the user
(and the program is waiting 99.9% for user's interaction, so reaction
time is not impacted).
Povray with a huge scene is not like that: it takes all the CPU it can
for rendering, and want to access unpredictable locations all the time.
You might help to keep the reaction time for the user in a reasonnable
area by using less cpu-cores (via the -WT option), if at least you have
more than one true cores.
Some operating systems can enforce a memory limit per process: once
reached, they kill the offender without negotiation.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> My computer just locked up due to lack of memory. I got a black screen
>> and had to reboot. Is this supposed to happen? Shouldn't POVray be
>> switching over to virtual memory?
>
> The system is in charge of virtual memory. Povray is just an application
> with sometime huge need of memory.
So it should probably give an option of a maximum amount of memory to
ask the OS for? I have similar issues with simulation tools on my
windows box, but they (the apps) all give an option to limit the total
amount of RAM used. If you set it just under the amount of physical RAM
then at least you get an error before things go very screwy.
The problem is when you have a scene (or simulation in my case) where
you've done something that unexpectedly asks for a huge amount of RAM
(eg typo in a loop or something). Before you have chance to realise it,
your machine has effectively locked up.
Does anyone actualy render anything that takes more RAM than they have
physically? Wouldn't it take a lifetime to render?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/13/2015 2:22 AM, Le_Forgeron wrote:
> Next time, open the task manager before starting the render, to see how
> it goes.
I am using Process Hacker 2. Not sure how to monitor swap usage. I can
only find the option to monitor physical memory, which does not take
long to deplete.
Can POV-Ray monitor this type of stuff? Would be nice to have it log the
info automatically.
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/13/2015 2:42 AM, scott wrote:
> So it should probably give an option of a maximum amount of memory to
> ask the OS for? I have similar issues with simulation tools on my
> windows box, but they (the apps) all give an option to limit the total
> amount of RAM used. If you set it just under the amount of physical RAM
> then at least you get an error before things go very screwy.
>
It might be nice to be able to set an upper limit on how much memory
POV-Ray is allowed to use and then fail gracefully when this limit is
reached.
> The problem is when you have a scene (or simulation in my case) where
> you've done something that unexpectedly asks for a huge amount of RAM
> (eg typo in a loop or something). Before you have chance to realise it,
> your machine has effectively locked up.
>
> Does anyone actualy render anything that takes more RAM than they have
> physically? Wouldn't it take a lifetime to render?
>
The Lego town I am working on takes a lot of RAM when you turn the
little top studs on.
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Next time, open the task manager before starting the render, to see how
>> it goes.
>
> I am using Process Hacker 2. Not sure how to monitor swap usage. I can
> only find the option to monitor physical memory, which does not take
> long to deplete.
You need to look how much RAM the POV process is using. If it's anywhere
near the amount of physical RAM in your machine then it's going to start
causing major slowdowns.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 13.08.2015 um 09:25 schrieb Mike Horvath:
> On 8/13/2015 2:42 AM, scott wrote:
>> So it should probably give an option of a maximum amount of memory to
>> ask the OS for? I have similar issues with simulation tools on my
>> windows box, but they (the apps) all give an option to limit the total
>> amount of RAM used. If you set it just under the amount of physical RAM
>> then at least you get an error before things go very screwy.
>>
>
> It might be nice to be able to set an upper limit on how much memory
> POV-Ray is allowed to use and then fail gracefully when this limit is
> reached.
If you are happy with a fixed limit of 3GB, a simple solution would be
to use the 32-bit version of POV-Ray.
As for setting an arbitrary limit, it should be no surprise that this is
something that's not portable across operating systems.
From what I'm finding on the 'net, on Windows machines "Job Objects"
seems to be a viable mechanism to achieve this. The idea would be to
tell Windows that it should simply pretend to POV-Ray that it is out of
memory if POV-Ray's memory requests exceed a given total size; POV-Ray's
failure mode would be the same as with the 32-bit version exceeding the
3GB limit. Whether this causes it to "fail gracefully" depends on
whether every nook and cranny of POV-Ray deals gracefully with an
out-of-memory condition; I currently can't vouch for that.
Alternatively, the front-end could continuously monitor POV-Ray's memory
consumption (it already does that for the status bar display anyway),
and if it exceeds the set limit it could send an abort request to the
back-end. This would make sure POV-Ray doesn't crash, and instead just
terminate the render; however, this mechanism may fail if memory
consumption increases too fast.
On Unix machines, the problem isn't that much of an issue, as operating
systems designed for multi-user operation are typically quite robust
against all sorts of ways an application could possibly run amok.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 13.08.2015 um 09:04 schrieb Mike Horvath:
> On 8/13/2015 2:22 AM, Le_Forgeron wrote:
>> Next time, open the task manager before starting the render, to see how
>> it goes.
>
> I am using Process Hacker 2. Not sure how to monitor swap usage. I can
> only find the option to monitor physical memory, which does not take
> long to deplete.
No need to look any further - if POV-Ray has to resort to virtual
memory, rendering performance will degrade fast, to the point where it's
pointless to continue the render. Worse yet, on Windows it will drag the
entire system into a state I call "Swap Hell", where even a simple thing
like opening the task manager may take half an hour.
> Can POV-Ray monitor this type of stuff? Would be nice to have it log the
> info automatically.
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).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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, at which time
any statistics are lost unless POVray stores them somewhere on disk.
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/13/2015 1:04 AM, Mike Horvath wrote:
> My computer just locked up due to lack of memory. I got a black screen
> and had to reboot. Is this supposed to happen? Shouldn't POVray be
> switching over to virtual memory?
>
> Windows 7 Pro x64
> 8GB RAM
> POV-ray 3.7.0.msvc10.win32
>
> Not sure how much swap memory got used up during the render.
>
>
> Mike
I just increased the size of the swap file to 32GB and that still wasn't
enough. Time to give up.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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/
?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/13/2015 10:07 PM, Bald Eagle wrote:
> 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/
>
> ?
>
>
I'm already using an SSD for my swap drive.
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
