Memory Issues in Solaris

[Martin_Davies]

Hi,

We are evaluating Arnold as a CPU renderer option from Solaris. We have been using various test scenes publicly available for download. Specifically, the SideFx market scene and Nvidia's attic scene. We are launching Arnold renders via Husk.

With the market scene, we are seeing RAM usage exceed 60Gb and the render seg faults. When I pass all mesh geometry into a render geometry settings node and set an arnold subdiv attr on each mesh we see it only use 16Gb of RAM and the render completes.

In the attic scene we don't see memory explosions and adding arnold subdiv attrs seems to make no difference to memory usage.

There are a few other differences between the scenes. For instance, the market scene has no normals on the mesh prims, orientation is leftHanded in market and rightHanded in attic.

Any insights into what could be causing high memory usage would be appreciated.

Thanks,
Martin

[Stephen.Blair]

If you Ignore Textures (Render Settings > Arnold > Diagnostics), does it still use a lot of memory?

Can you try kicking the usd file (with -it) ?

C:\solidangle\htoa\htoa-5.6.3.0_ra766b1f_houdini-18.5.596.py3\htoa-5.6.3.0_ra766b1f_houdini-18.5.596.py3\scripts\bin\kick -v 5 -dp -dw -it example.usd

[Stephen.Blair]

What version of the scene are you using? Is it based on a specific hip file in the solaris demo files?

[pal.mezei]

I think this is due to how subdivision settings work in Hydra. There are two ways to setup subdivision settings, one is using the Arnold tab on the RenderGeometrySettings LOP, the other one is something called "displayStyle", which is a Hydra internal class. By default, hydra sets the refinement level at a high value, triggering subdivision in Arnold that leads to the increased memory usage.

One of the options for us would be to ignore the settings from Hydra and rely on the Arnold specific geometry setting.

[Martin_Davies]

Hi Guys,

Thanks for the suggestions. Using the diagnostic options made no difference.

It looks like Pal's suggestion that Hydra subd settings are being used is the culprit. The attic scene already had the attr subdivisionScheme set and the market scene had no subd attrs set on the mesh prims at all. I'm assuming Arnold doesn't care whether the subd attr set is an arnold attr or not, as I got Arnold to complete and not blow up memory by setting the standard subdivisionScheme attr on all the mesh prims.

From testing some other renderers, it seems that they ignore Hydra settings (in the subd case anyway).

[Stephen.Blair]

If it was possible to get an Arnold log, we would have seen the memory breakdown and that would have showed that subdiv was the culprit 😉
I went with the log suggestion in case it was something else...