|
 |
"jhu" <nomail@nomail> wrote:
> Currently, 15GB on my computer that only has 16GB! It's headless and still
> responsive. Then I realized why, rearranged the code, and went back down to
> using 6GB.
Just under 3.5GB out of 8, on my i7. I was just testing the computer's
performance at that amount of memory usage and data i/o by rendering a
16384x16384 image. After a few minutes, I was convinced of it's powers... ;)
D103
Post a reply to this message
|
|
|
|
jhu wrote:
> Currently, 15GB on my computer that only has 16GB! It's headless and still
> responsive. Then I realized why, rearranged the code, and went back down
> to using 6GB.
The revisited Asbak image I posted a little while ago used 28GB.
--
Ger
Post a reply to this message
|
|
|
|
Am 04.07.2012 02:01, schrieb jhu:
> Currently, 15GB on my computer that only has 16GB! It's headless and still
> responsive. Then I realized why, rearranged the code, and went back down to
> using 6GB.
11 GB out of 6 (!), testing a bugfix for an error scenario involving a
86400 x 43200 pixels PPM image map (requiring 10.4 GB alone). Most of
the render time consisted of loading that image map into memory. The 64
bit Windows 7 system stayed comparatively responsive, despite obviously
having to utilize virtual memory. (The bugfix proved effective; the
earlier 3.7 RC5 would instead erroneously allocate far less memory and
then crash.)
12 GB out of 6, trying to render to a 86400 x 43200 pixels PPM output
file (guess for what purpose). The image data was accumulated on hard
disk in a 69 GB temporary file (which took 20 minutes even to create)
rather than main memory, but memory consumption still kept rising during
render for then-unknown reasons, ultimately resulting in a crash of
POV-Ray when the (fixed) virtual memory limit was hit. The 64 bit
Windows 7 system had become totally uncontrollable by then.
Lesson learned: On Windows systems, do /not/ attempt to render simple
scenes like a chrome sphere on a checkered plane at excessively high
resolutions. It turns out that the render threads may pump image data
into the inter-thread message queue at a faster rate than the front-end
thread can write them to their designated location in the temporary
file, causing the message queue to grow slowly but steadily past all
limits. (I guess that having virtual memory on the same physical disk as
the temporary file will make things even worse as soon as swapping sets
in, by reducing I/O performance even more; I didn't bother to try - my
swap file is on a separate one, and that was bad enough.)
Post a reply to this message
|
|
