On 10/5/21 5:42 PM, Kenneth wrote:
> [in Windows]
> Confirmed in v3.8.0 beta 1 (v3.7.0 can't use this feature, otherwise I would
> have tested it there too.)
> 
> While trying to track down where the memory increase might be coming from, I
> instead wrote a*bare*  test scene-- with nothing but the changing cameras! Yet
> the memory-use still increases.
> 
> Try running just this scene in your povr branch to see what happens:
>   -----
> #version 3.8;
> global_settings{assumed_gamma 1.0}
> 
> // MULTIPLE CAMERAS:
> #declare CK = 0;
> 
> #while(CK <= 1.0)
> camera {
>    perspective
>    location  <0, 25, 40>
>    look_at   <0,0,0>
>    right     x*image_width/image_height
>    angle 67 // 67
>    rotate 360*CK*y
> }
> #declare CK = CK + .05;
> #end
>   -----
> 
> [But WARNING: On my i7 8-core machine, this runs SO fast that the 'stop' button
> doesn't reliably work; I had to shut down POV-ray instead. OR, what also works
> for me: Hit 'pause'-- which does pause the looping animation temporarily-- then
> hit 'stop'. The looping still proceeds x-number of times before coming to a
> final halt-- but the memory use starts to slowly*decrease*  while that happens.
> That's interesting by itself.]
> 
> My own 'working hypothesis' at the moment is that ALL of a scene's code and
> elements are being duplicated for each 'new' loop, not just any image_maps...
> and that each loop's 'new' memory use adds to the previous total.

Thanks! I didn't think to try larger render windows with just cameras. 
My non HDRI stuff was what I already had - small isosurface changing / 
morphing things and there memory is always small, but the frame rate and 
render sizes are smallish too.

If you get a chance, I'd be interested in a single thread run on your 
machine/windows. I'm actually getting better reported FPS that way than 
using 2 cores / 4 threads - which on the surface doesn't make much sense.

Playing around just now I had the thought to try -D to turn off the 
preview display and it does change the rate at which the memory bubble 
grows.

Aside 1: You've probably noticed too that pause/un-pause screws up the 
fps reporting.

Aside 2: Given what we see here, I'm wondering how much the freeing and 
re-allocation of memory is costing us 'during' normal single frame 
renders. c++17 / c++20 I understand will have more in the way of inbuilt 
memory pre-allocation / re-allocation (for memory locality of reference) 
and control - not that I currently have a clue how to make use of any of 
those features at the moment... :-)

Aside 3: I run rtr/kla renders with -cc and -fn too, to be sure I'm not 
creating the continuation and image files - or portions thereof. Which 
likely also changes behavior, but not explored much.

Bill P.

Post a reply to this message