PDA

View Full Version : Nuke Not Using Multiple Processors During Render?


evolross
07-21-2010, 04:24 PM
I'm using Nuke 5.1 and whenever I'm working in Nuke or doing a render, the CPU barely gets used and usually hovers around 5 percent. It also uses very little memory. Both working in Nuke and rendering are very slow compared to working in After Effects.

I'm running a dual-quadcore Xeon machine so I have 8 cores available and 16GB of RAM. So it's unsettling that Nuke is using such little resources.

I'm pretty sure it's not the network as when I work on very, very complex comps in After Effects and render, it pegs all eight of my processors to almost 100% and uses as much RAM as I'll allow it to.

I've checked the number of threads using the "return $threads" command and it returns 8, so that seems to be set right. Is there another place to enable multi-processor usage?

alkali22
07-21-2010, 04:35 PM
The most common limitation, even for high-end systems, is a lack of adequate disk or network IO to keep Nuke's rendering architecture saturated, and it produces symptoms pretty much exactly like what you're describing. What kind of network infrastructure are you working from, and what size and volume of image data is being pulled?

evolross
07-21-2010, 09:03 PM
I am on a bit of a fussy/slow network. It oftens hangs when I'm navigating in Windows Explorer looking for files, etc. It's a basic home network, that's been extended to be a little larger (as far as I know, I'll look into this a little further). Is there anyway to test my bandwith on the network? Would bandwidth be an indicator?

I've even resorted to rendering the comp in Nuke on three different machines, each rendering a third of the frames. They all render slowly, but they don't seem to render any slower because there's three machines all attacking the network for CG frames... if the network were the bottleneck, wouldn't multiple machines mean even slower render times?

And in the comp, I'm working in HD and maybe reading in 10 to 15 different 16-bit CG renders (I'm currently using SGI RGB as my image format). So it is pulling in a lot of imagery.

But I was confused that AE seems to handle a comp like this so much faster on the same network.

beaker
07-21-2010, 11:16 PM
What version of 5.1 are you using and is it the 32/64 bit version? 5.1 is 2 years old and we have had 20-25+ point releases and 2 large update since then(5.2 and 6.0). Also there we're some threading bugs back then, any chance your company is on support and could upgrade to 6.0?

evolross
07-22-2010, 04:34 PM
It's 5.1v5 64-bit. Was there a lot of point releases after this version?

I'm not sure what support the company has. Although I was told this morning that the network is a Gigabit Ethernet so that should have the bandwith to keep up right?

alkali22
07-22-2010, 04:44 PM
The network sounds like a likely culprit here. Since Nuke's rendering architecture is scanline-based, it makes lots of IO requests for individual scanlines from each input file, and on an inadequate network, this can result in a lot of latency between each scanline request and Nuke actually receiving the data, even if the bandwidth is there. It basically sounds like either the file server is overloaded serving data (its internal storage isn't fast enough), or the network is just getting oversaturated with traffic (low-quality switch, etc).

Try copying your footage to whatever local storage you have (RAID or just local disk) and re-linking the comp. At a minimum, the read latency should be much lower than it would be through an overloaded switch. Also, go through your comp and be sure your BBoxes are optimized as much as possible... this can be the difference between minutes and hours of render time.

nrgy
07-22-2010, 05:10 PM
Not all nodes are multi-threaded. Convolves, defocus...

cgbeige
08-07-2010, 06:32 PM
if you have a hyperthreaded machine, you might need to do what I do and set the thread count manually. I have a dual 4-core Nehalem Xeon Mac Pro (16 threads) and Nuke only uses 8 until I enter this script (hit X to open the TCL script thing):

set threads 16

obviously that depends on how many cores you have. If you want to check how many cores Nuke is using by default, leave out the number and it will report:

http://grab.by/grabs/5c75262b26137bd7a16f7d5d1071f14b.png

CGTalk Moderation
08-07-2010, 06:32 PM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.