OPs such as Mountain.

Reason I am asking is, when would you want to control this? Should OPs that support multi-cores not use all cores available whenever possible?

Just curious as to when one might need to actually specify this.




Thanks.

You might wanna save some threads for rendering or to make sure it don't lock up your computer by hogging all cpu.

I was assuming that too, but I thought the operators would compensate for that automatically. I don't know how Houdini rendering works, but for the UI, it could probably leave one of the cores out automatically, so the artists would get the best performance possible without sacrificing interactivity.

Anyway just curious, I am probably oversimplifying it

magneto
I was assuming that too, but I thought the operators would compensate for that automatically. I don't know how Houdini rendering works, but for the UI, it could probably leave one of the cores out automatically, so the artists would get the best performance possible without sacrificing interactivity.

Anyway just curious, I am probably oversimplifying it

The only nodes which allow you to control multi-threading are those based on VEX. These are very specific types of operators spread across all Houdini's contexts. In SOPs they are either VopSOPs or VEXSops (others are *CHOPs and *POPs). MountainSOP, is internally a VexSOP executing some noise function on a geometry.

These nodes types exploit a VEX virtual machine which by design allows an user to control a number of threads it will consume, since it's a SIMD machine par excellence (http://en.wikipedia.org/wiki/SIMD). [en.wikipedia.org] Being able to set it per node gives lots of flexibility because not always executing vex code in parallel is desired. (You may want to share cores between many operators, your code could be thread unsafe, or it could execute faster in single thread mode.)

Besides VEX case, Houdini and Mantra multi-threading is controlled by a single -j command line switch, but by default they both use j==num_cores since they hardly ever work concurrently in parallel.

Thanks Symek, your knowledge of Houdini always impresses me. Very cool info.

Also I see VOP and VEX all the time, but not sure what their difference is? VEX OPs are VOPs, no?

Another reason I was wondering managing number of threads per OP (that supports it) is when the networks get huge, it would be pretty tricky to manage them.

But the reasons you outline makes sense.

Is there a way to disable the ability to change it? For instance if you know your VEX code is not thread safe, etc.

Thanks for clarifying the Houdini and rendering btw. I was also thinking they wouldn't have to run in parallel.




Cheers.

Hey magneto , I believe that just like any SOP you can RMB in the node and open the edit parameter interface window. From there you should be able to mark existing parameters as invisible (never tried with Vex sops but I would imagine it be possible)

Thanks Gray. If that's doable, that would be useful IMO.