To all NUKE users: NUKE not utilising HW well enough - please help

[PIXELBOX_SRO]

Hello guys,

today we have installed a fully unlocked NUKE 8 DEMO and tried the most simple setup we can actually think of.

READ NODE - VECTOR BLUR - Z DEFOCUS set only to affect RGB - WRITE NODE

We are feeding NUKE with EXRs with approx 20 layers, but in the script were using only 3 of those.

The animation is 420 frames long and FUSION can handle it in about 5 minutes, utilising all the cores and threads at 100%.

BUT

NUKE handles this in whopping 33 MINUTES!!! While utilising the processor only from 8 percent.

This doesnt seem right at all for a 5K piece of software.

Here is a screenshot:


We have this HW:
i7 HEX running at 4Ghz
64GB RAM
all the files loaded/written from/to a PCIE SSD REVODRIVE 3 x2
NVIDIA GTX TITAN

There is no reason for the resources to be so badly utilized.
There is also no bottleneck in the system i can think of

Set Threads in NUKE says were using all 12.
GPU speedup of the Zdefocus node is not very evident.
I really doubt that such nodes as Zdefocus and VectorBlur would be single threaded???

Were considering a purchase but this is something that would clearly STOP us from even thinking about it.
Of course we could run multiple instances of NUKE but for such an expensive SW, thats a bit weird workaround :-/
Another workaround could be to run multiple renderings on the same machine through DEADLINE but i am not sure its even possible.

So to sum up, i guess we must be doing something wrong.

Please help!

Thanks a lot

Best Regards

[vlado]

Might be good to also post on the Nuke forum or contact The Foundry for support.

Best regards,
Vlado

[joconnell]

Yep -the foundry are pretty pro active on their development, I'd definitely give them a shout on twitter. It might be a case where they just write in multiple render threads into one single render operation so it's similar to doing multiple instances. I agree though, that's a big waste of a lot of power!

[PIXELBOX_SRO]

i wrote here first because i am waiting on their administrators to activate my forum registration.
Unfortunatelly its taking forever and i only have about 3 days to make a decision the purchase

[vlado]

Btw are the EXR files multi-channel? If yes, do they use scanline ZIP compression? Older V-Ray builds used to write by default ZIP16 compression which was slowing down Nuke a lot.

Best regards,
Vlado

[PIXELBOX_SRO]

EXRs are multichannel, converted from VRIMG with ZIPS compression option.
I am using this to convert the files

vrimg2 exr filename*.vrimg -compression zips

We cant unfortunatelly write to EXR as we get lots of unsaved errored saves over Backburner.

Question is whether the convert did the job right?

[vlado]

You can check that with the exrheader tool from the OpenEXR library - let me know if you don't have it, I can upload it somewhere.

Best regards,
Vlado

[PIXELBOX_SRO]

no I dont have it unfortunately could you please upload it?
Big thanks Vlado!

[joconnell]

Pixel - make sure you also use -datawindow in your conversion too. This'll allow nuke to skip over all the empty pixels in a scene and only process where there's actual data. It makes a huge difference.

[vlado]

no I dont have it unfortunately could you please upload it?

You can find it here:
https://ftp.chaosgroup.com/vlado/exrheader.rar

It's a command line tool, I trust you'll figure out how to use it

Best regards,
Vlado

[PIXELBOX_SRO]

Thanks a lot John and Vlado!!!
Will have a look at this in the morning and report the changes.
No sign of the forum registration activation on the foundry... Hopefully they will resolve that soon so i get some input from them too. Surely the first thing is to have the source files converted the right way thanks to your suggestions i hope to resolve that tomorrow
Cheers!

[PIXELBOX_SRO]

the exr header says:

compression (type compression): zip, individual scanlines
dataWindow (type box2i): (0 0) - (1919 1079)
displayWindow (type box2i): (0 0) - (1919 1079)
lineOrder (type lineOrder): increasing y
pixelAspectRatio (type float): 1
screenWindowCenter (type v2f): (0 0)
screenWindowWidth (type float): 1

so i guess the VRIMG was converted well yes?

i dont understand the datawindow text though.....is it set well or not? or shoudl i reconvert with the -datawindow option as John suggested?

Thanks for the support guys!

[vlado]

The data window is not set (it's the same size as the display window); you could try reconverting with -dataWindow but you said that Fusion doesn't need that and it's still faster, so it's odd.

Best regards,
Vlado

[PIXELBOX_SRO]

ill reconvert this as do some testing in both apps.
Thanks Vlado!

[PIXELBOX_SRO]

i use this string:

- compression zips -dataWindow -bufsize 50

and got this:

compression (type compression): zip, individual scanlines
dataWindow (type box2i): (0 0) - (1919 1079)
displayWindow (type box2i): (0 0) - (1919 1079)
lineOrder (type lineOrder): increasing y
pixelAspectRatio (type float): 1
screenWindowCenter (type v2f): (0 0)
screenWindowWidth (type float): 1

which doesnt seem to reflect any data window parameter...why is that? The data window is still the same as screen window.

the beauty pass is fully covered with pixels but there are many layers with mask which should be clipped no?