Can we have an adaptive sampler compact mode ? :)

[maxtarpini]

Jeez guys, just realized that for example at 4k with the default 20AA and a couple of AOVs, the adaptive sampler is taking up to 1GB memory and for what ? I don't need all the samples available at the end 🙂 Would be feasible to have a kind of compact mode where at each bucket the samples are flushed ? I'm rendering a simple ball at 16k resolution and at some point is taking up to 15GB .. this is plain crazy.

(edit at 16k it does not even flush the samples after the rendering is done, so I thought that setting a new size for the render image would kinda do that.. nope, - it kept adding stuff to memory until it got to swap and crashed)

ubuntu, mtoa

[DeclanRussell]

Hey max,

Sorry for the overdue response on this. We've made a bunch of improvements in the last couple of releases regarding our memory management here. I tried a similar scene to the one your describing and rendering this as 16K gave me a peak memory of around 3.6GB which is a little more reasonable. Can you confirm that this is the case for you?

[maxtarpini]

Hi Declan,

spent some little time trying to break Arnold 🙂

Scene is a simple sphere with a plane and an arealight.

((Arnold 6.0.2.1, MTOA 4.0.2.1, Ubuntu 18.04.5))

resolution: 16k X 9K, AA=3

--------

If I 'disable(d) by sample' (ie. put to 0 the sample of) the other buffers..

(MAYARENDERVIEW) Goes to swap (32GB).

(RENDERVIEW) It eats up around 8GB.

(KICK -dw) It eats up around 3.8GB.

---

If I have 1 (ie.9) samples also for the diffuse and specular buffers with their AOVs enabled..

(MAYARENDERVIEW) Goes to swap (32GB).

(RENDERVIEW) It eats up around 15GB.

(KICK) Eats up around 6GB.

---

Same as above but with Adaptive Sampling enabled (default settings)

(MAYARENDERVIEW) Goes to swap (32GB).

(RENDERVIEW) It eats up around 16GB.

(KICK -dw) Eats up around 7GB.

---

Sry, but it doesn't look much has changed. However it also makes sense not to render such a resolution directly within mtoa and in fact I don't see too much problems with kick.

[thiago.ize]

1GB extra to enable adaptive sampling on a huge 16k x 9k image seems reasonable. The big memory usage seems to be on the mtoa side when dealing with large images and possibly lots of AOVs (could it be setting samples to 0 doesn't actually disable those AOVs?).

Generally, if you write images to disk using tiles, memory usage won't be so bad. I suspect that mtoa (MAYARENDERVIEW and RENDERVIEW) are keeping all the these output buffers in memory so that they can be displayed and this is what is using up all the memory. We need to investigate why MAYARENDERVIEW is more than RENDERVIEW.

[maxtarpini]

Yeah I think it's more of a problem in mtoa than in arnold core. The Kick tests are using tiled exr.