unloading ram after render... sloooooowww..

[super gnu]

ive got 20gb of vray fur in my scene... take a while to fill up the ram and really crank the rendering on.. thats understandable.. but after rendering finishes (or is cancelled) , i have to wait several minutes as the ram ----gradually-- empties.. whats it doing? the bandwidth of my ram means you could theoretically fill/ empty it in a couple of seconds.. and surely in this case it just needs to dump the data...

[vlado]

ive got 20gb of vray fur in my scene... take a while to fill up the ram and really crank the rendering on.. thats understandable.. but after rendering finishes (or is cancelled) , i have to wait several minutes as the ram ----gradually-- empties.. whats it doing? the bandwidth of my ram means you could theoretically fill/ empty it in a couple of seconds.. and surely in this case it just needs to dump the data...

When rendering the fur, V-Ray allocates relatively small chunks of memory as it goes along. At the end of the render, these chunks are deallocated one by one. After each deallocation, the C++ runtime does some work to tidy things up and keep the memory space organized. It is this additional work that causes the slowdown.

There are ways for us to improve that and I hope we'll get to that at one point.

Best regards,
Vlado

[super gnu]

well at least now i can look at it gracefully emptying the ram, and think to myself.. there goes that c++ runtime.. doin its thing

[3LP]

Yeah, we have that issue all the time with big scene using up to 32Gb of ram.
The most obvious is when spawning, the nodes are not picking the second spawning job (or the third one, they only pick up the first one) so we need to kill 3dsmax instance before each render.
A pain that implies constant monitoring, but we haven't found any other solution for big scenes...

Stan

[Svetlozar Draganov]

Yeah, we have that issue all the time with big scene using up to 32Gb of ram.
The most obvious is when spawning, the nodes are not picking the second spawning job (or the third one, they only pick up the first one) so we need to kill 3dsmax instance before each render.
A pain that implies constant monitoring, but we haven't found any other solution for big scenes...

Stan

Have you tried to activate "Restart slaves on render end" from Vray Distributed Rendering Settings.
With this option activated Vray Spawner will be restarted after each finished job - and it should pick the next job without the need to restart Max manually.

[super gnu]

i always have this ticked.. however in this scenario, the slaves take so long to sort themselves out after rendering, that they dont reach the "render end" by the time you send the next job. this is mainly noticeable if your render nodes are slower than your workstation, otherwise they all take the same time to free up, so you dont get the dr problem, just the "staring at the screen and waiting" issue.. however i guess most of 3d involves staring at the screen and waiting....

[Svetlozar Draganov]

Yes if the slaves are slower they will need more time to free up the memory but even so they should pick the next job because the workstation machine starts sending information to the slaves when they are ready even if the render is semi-finished.
However if the scene is too heavier and you have a lot of geometry and external assets it would be a good idea to optimize everything.
For example you could use vray-proxies and to export all heavy geometry to external files - also it is better to make a local copy of your project to each slave and load all assets from local machine instead of workstation.

[3LP]

Yeah I tried that option, but it doesn't help

It might be a plugin issue (the old colorcorrect for ie) is blocking max to close, and then it's not only a geometry load problem, but a code issue due to the plugin.

We don't have any colorcorrect anymore in our scenes, (we use a script to delete it from the scene) but when the geometry load start to be high, the nodes don't pick up, but they don't release the ram ether, even if it stays there for a night...
We have 1 computer our of the 50 nodes that is using every job no matter what, and I already investigated, but I couldn't found any reason why that node does pick up (and release ram) and all the others not...

I think it's a combination of things, and you guys are right, I'm sure it's working if you take a fresh scene of max, put 3 billions teapots in and render, but, unfortunately, it's not that simple in real work.
We might have got geometry created by all sort of packages (revit, archicad, etc), textures that are carrying on from projects that are 2 years old, loads of plugins because it's how it is.

And at some stage, spawning with high geometry doesn't work anymore, so we bite the bullet and kill max between each render.

Stan

[Svetlozar Draganov]

Yes we understand that production-projects are different than test scenes and it is not so easy to find out what exactly is the root of the issue.
Usually using external geometry always cause some kind of troubles and I wouldn't be surprised if the issue is related with it.
However - do you have the same behavior with all scenes or the issue is scene-dependent ?

[super gnu]

ok just to re-hijack my thread about vray fur, i was quite casual about it but ive realised it (obviously really) also does it between frames when rendering an animation so thats added 20% onto my rendertimes just housekeeping the ram.. is the performance hit from having messy ram more than the massive wait for it to be tidied up? i guess so or you wouldnt do it. shame the data cant be reused between frames.. the fur (apart from stuff that wasnt visible in the previous frame) doesnt change over time...