Le 05/10/2010 19:08, Warp nous fit lire :
> Le_Forgeron <lef### [at] freefr> wrote:
>> and keep in mind that when writing the final file,
>> you need yet another chunk because most libraries use a memory approach
>> too (but it is usually only 3 or 4 bytes per pixel), even if they
>> compress later the output before reaching the disk.
> 
>   Most image format read/write libraries support reading/writing the image
> in small portions at a time, for this precise reason. For example, pnglib
> only requires a few kilobytes of RAM to write even huge PNGs, and you can
> feed it pixel data in small groups.
> 
>   So converting the image to 8-bit-per-component RGBA and writing to PNG
> shouldn't be the problem (because the conversion can be done a few pixels
> at a time).
> 

You are correct.
But testing an empty scene (well, 1 camera, 1 light source) with a 20500
x 20500 size gives the following observations:
(-A -D)

memory used on system jumps to 9.6G at the render start.
It raises as it progress to 16G.
When file-write start, (1 & 1/4 active threads), memory stay at 16G.
Then drops to 9.1G and only 1 thread stays with 100% while the write
finishes... a delay might be observed once the write ends and before the
program exits (sometime).

The 25% thread might be some garbage collector... but it looks like
there is a memory leak while rendering (I would have expected all
allocation do have been done once all rendering threads have been
created (well, short of temporary objects like intersections stacks...)

6.4G is not a small increase.

Note to self: best WT values (for a huge & empty scene) of cpu
efficiency seems to be number of HTcores -1 (so the scheduler push them
full frequency). As soon as WT number reaches number of cores, they are
slowed down to approx 60% on the system chart. (thread collisions is
probable)

Post a reply to this message