Problem summary
Playing back the Nuke Viewer when Filter nodes are used on Read inputs on a GTX 980 is inconsistently slow. On random frames, the time to load a frame would increase massively, and the CPU would show 100% usage on all cores in the Task Manager. Rolling back to older versions of QuickTime seems to help, as does older versions of Nuke.
Customer reported version
nuke.9.0v8
Customer reported platform
windows7
Steps to reproduce
1) Use a machine with a GTX 980.
2) Open Nuke
3) Create a Read node with an input from a local drive, my test .png sequence is attached
4) Create a second Read node with an input from a local drive
5) Create a Merge node and connect one Read node to input A and the other to input B
6) View the Merge node and play back the viewer, it should buffer very quickly
7) Create a Glow node and put it between the Read node and input A of the Merge node
8) Play back the viewer and on random frames the playback will take ages to generate a frame. If you look at the Task Manager, all logical cores will be at 100% usage. Adding more Filter nodes, such as Blur or Defocus makes the issue more apparent.
On further testing I found that if you use the -m flag with less logical cores than the computer has, the problem does not occur.
I also found that if you use older versions of QuickTime seems to help this issue, however when you have more Filter nodes, the issue re-appears.
Reproduced by support
The problem was reproduced in:
Nuke 7.0v10 Windows 7*
Nuke 8.0v6 Windows 7
Nuke 9.0v8 Windows 7
Nuke 10.0v1 Windows 7
*It was more stable in Nuke 7.0v10, so needed many more Glows and Defocuses before the issue occurred.
Expected behaviour
For Nuke to generate the Viewer frames at a consistent rate.
Actual behaviour
On random frames, the time to load a frame would increase massively, and the CPU would show 100% usage on all cores in the Task Manager.