Slow Displacement calculations

[Matt688]

I am trying to optimize a scene I have been working on and am running into trouble while calulating my dispalcement map, its seems that only 1-core (i have 8) is being use while the displacement is being calulated. After the displacement is finished being calulated all 8 cores run as they should. I am using a custom procedural shader to generate the displacement. I have tried this in Windows / Linux and get the same result. I am hopeing there is a check box somewher I am missing or just the knowledge that its just the way things are.

Here is an example file that uses a similar shader and has the same issue, everything renders fine I just feel there has got to be a faster way to generate my displacement.

Any help is appreciated.

displacement_issue.hipnc

[symek]

Why your grid is so dense? This is the only reason to slow down I see here. It could be 10x10, really this doesn't make any difference for displacement effect in Mantra. It dices polygons into micro-polygons anyway. Other than that, you should also adjust displacement bound to the amount of expected displacement. That pretty much all.

[Matt688]

Why your grid is so dense? This is the only reason to slow down I see here. It could be 10x10, really this doesn't make any difference for displacement effect in Mantra. It dices polygons into micro-polygons anyway. Other than that, you should also adjust displacement bound to the amount of expected displacement. That pretty much all.

I discovered that when mantra is dicing the geometry for displacement the process is single threaded, hope this changes in twelve, Thanks Skymek, having a grid with less subdivisions would work, for the scene I am using this shader on is pretty dense and thats what the grid was representing, I have tweaked my displacement bounds down to get me managable render times.

[lukeiamyourfather]

I discovered that when mantra is dicing the geometry for displacement the process is single threaded, hope this changes in twelve, Thanks Skymek, having a grid with less subdivisions would work, for the scene I am using this shader on is pretty dense and thats what the grid was representing, I have tweaked my displacement bounds down to get me managable render times.

Not sure if that will change in future versions of Houdini, hopefully it will as it was an issue for me previously. Regardless of whether it changes this is something everyone working in computer graphics should read (if you haven't already). As machines with more and more cores are becoming available but with similar frequencies this is more and more important for what we do.

http://en.wikipedia.org/wiki/Amdahl%27s_law

The larger the sequential portion of the render the less efficient it becomes. To get maximum efficiency from the hardware when rendering sequences you'd want X concurrent renders for X processor cores and enough memory and throughput to satisfy all of them. For example if a single frame on an 8 core machine takes five minutes but one minute of that is displacements then (assuming there's sufficient memory and throughput) 8 frames could be rendered in 34 or 35 minutes since the other 7 processors wouldn't be idle for 20% of the time. That's an improvement compared to waiting 40 minutes for the machine to render 8 frames one after another instead of concurrently.