Jump to content

Multithreaded Geometry Rop?


Recommended Posts

I'm brand new to houdini and doing some tutorials. I've got a heavy bit of metaball geometry writing out to disk using a geometry rop and it seems to only use one proc of my 4 proc system. Is there a way to distribute it to all 4 procs? There is nothing in the network that I know of that would force it to be a linear frame dependant cook.

Thanks in advance

Link to comment
Share on other sites

No, there's not. Most of the geometry library and SOPs is not threadable, so it cannot take advantage of multiple CPUs.

22395[/snapback]

I was more hoping to find a way to render the geometry rop individual frames to different cpu's at the same time. There's probably no way built into houdini for it to automatically cook a frame per processor but there must be a way to drop batches of frames on each processor, through a command line maybe?

Link to comment
Share on other sites

I sort or investigated this... Thinking out loud here.

It seems like it might be possible to do with a shell script in Linux, I haven't really looked at Windows, but it may be possible there as well because I believe Windows does allow you to bind processes to CPUs (I don't know if you can do this through a shell though). Since it seems you can fire up multiple Houdini sessions on the same box without eating up extra licenses it should be doable with a bit of effort.

What I found out is that Linux does not really support processor affinity. It has a scheduler that tries to keep processes bound to specific CPUs but you cannot force a process onto a specific CPU yourself. Linux is supposed to mange the load. What hopefully should happen is that if you fire up 4 Houdini sessions, each one *should* get it's own CPU and stay there... according to what I read at least ;P

So what I think you would require here are a couple of small scipts. The simple way to do it, that I can see, would be to save out your file. You then write an Hscript that renders out geometry based on four arguments, start frame, end frame, the /path/file.hip and /path/file.$F4.bgeo. So this hscript, loads up a hip then renders out an arbitrary segment of frames to a series of bgeo files.

The above script gets called by a shell script. The shell script takes the start and end frames of the enitre animation, a variable for the number of processes to spawn, the source hip file and the path to save the output to. The shell script would divide the entire frame range into segments by the number of processes you request to spawn, and then call the hscript as many times as you have specified with the variable for number of processes, with the various frame range segments and the hip and output files you specify.

In theory this should work although it wouldn't be as fast a a real multithreaded ROP.

Other than that you could look into an opensource scheduler/manager like grid engine and try that.

This idea though, sounds like it might be useful. I'll take a stab at it over the weekend.

Link to comment
Share on other sites

Even when using a multithreaded applications (like COPs), the threads are not guarenteed to stick to a certain processor. So you're not really losing much here by spawning separate processes - you just have to trust that the OS scheduling algorithm 'does the right thing'. Your main inefficiencies would be 1) the time to load 2 copies of Houdini + hip file and 2) having 2 copies of Houdini + that hip file in memory. You could do something like:

echo "render-f 1 100 -i 2  /obj/geo1/rop_geometry1; quit" | hscript myfile.hip &
echo "render -f 2 100 -i 2 /obj/geo1/rop_geometry1; quit" | hscript myfile.hip &
wait

This spawns two hscripts, and renders all the odd frames on one and the even frames on the other. The script will wait until both have completed. Such a script would be reasonably easy to generate and execute from hscript.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...