13k render + Denoiser render element = out of memory

[Fredrik Averpil]

Hi,

This is more of a question than a problem;

We have a quite simple interior scene which consumed more than 64 GB of memory in order to render and was unable to render on Linux (due to a crash). In comparison to other projects, this is a quite typical kind of scene which really doesn't usually consume much memory at all. However, in this case we are rendering in 13k res, which can throw a lot of the general rendering expectations out the window.

- The scene crashed on Linux but rendered fine on Windows although it consumed all of the RAM available (64 GB on both platforms).
- We managed to get the scene to render eventually, by lowering "Max tree depth" under "System/advanced" from 80 to 20 (number by guesswork).
- It also turns out that we were using the "Denoiser" render element. When removing that and resetting the "Max tree depth" back to 80, the scene rendered fine without crashing (although it still consumed a lot of memory).

Question: Are you aware of any issues using the "Denoiser" when rendering very large resolutions? (perhaps the Denoiser is RAM hungry?)

[yolov]

Were you using the adaptive or progressive sampler? That's a CPU render I assume, not GPU, correct?

[Fredrik Averpil]

Adaptive and CPU.

[yolov]

Is the denoiser ser to denoise or to only generate the necessary channels for denoising with the standalone tool later? If it's set to denoise where exactly in the rendering process does it go out of memory - while rendering or while denoising at the end of the render? Ideally, we could look at the scene if you can send it over. Is that a GUI render or batch? With VFB or without memory buffer? What are the machine specs?

[Algehov]

Sorry for a late reply. We'll see if we can provide you with a scene that replicates the issue.
But to answer some of the questions:
The denoiser is set to denoise (after the render is complete, but it never reaches that stage).
I think the scene caps out on memory in the beginning when it starts rendering, after having compiled all geometry, etc.
The scene is not this memory heavy when rendered in 4k. But on 13k it eats it all up. We slice up the render in different render regions, so nothing renders the 13k pixels all at once (except LC thats being baked). But I guess maybe it it still have to load all of it for 13k in memory? (expecially displacement set to view dependant, etc).
I can only assume that its the rendering part of one of the extra denoise-passes that makes it crache on Linux, and not the denoise process itself, as it never reaches that stage.

Its a batch render, and its without the VFB.
Do you want specifics on the Linux nodes in what CPU/Type of RAM/etc? They got 2 6 core CPUs (So 12 cores) and 64 RAM. I can look up more detailed specs if needed.

[yolov]

That would suffice for the moment. A scene would be helpful.
The first thing that comes to mind when you say that it goes out of memory before denoising is the render channels - the denoiser itself adds several render elements and like all render elements - that consumes RAM. You can check your settings for the denoiser and see if you're using "Depending on denoising type" for how the render elements are generated. This would help reduce the number of channels and the RAM usage if you're using the Single pass denoising mode.

[Fredrik Averpil]

Unfortunately, the ball was dropped by us on getting this scene, logs etc to you guys.
As far as I understand, the scene was finally successfully rendered by completely not using the denoiser in order to deliver the project in time for Christmas.

I can send the scene to you guys, but the settings doesn't reflect the settings used in the scenario where we were having issues. Also, all of the render logs have been purged from our server and are no longer available.

However, I'm now sending you other projects as we are getting RAM issues with the very same V-Ray version: http://forums.chaosgroup.com/showthr...scene-on-Linux

I don't know if this could be related or not but figured I'd at least let you know we completely dropped the ball on this one... :/