Low CPU Utilisation when rendering DVO Flickr
Hi, just thought I'd try the forum to see if anyone has any insight.
I'm working on a project with 4k scans from a Cintel, transcoded to DPX. Working in half-float and caching in EXR PIZ.
When rendering DVO Flickr I'm finding that I get very low CPU utilisation. When looking in Task Manager it hovers around 25-28%. It appears to be using all the available cores, just at a very low level. I'm used to hearing the fans kick in when I start rendering something with Phoenix, but currently it isn't even breaking a sweat (because it's going so slowly).
When I render other effects it is behaving normally, 100% across the board, fans kicking in, etc.
The PC is a dual Xeon (36 cores) build which was built to Filmworkz spec (admittedly a few years ago now). Hyperthreading and NUMA are turned off. We've recently put all our machines through a load of tests and this was The Fast One.
If anyone has any suggestions for things I might be missing I'd be very grateful.
-
Hi Silas Dominey ,
Can you give some info about your computer specifications, especially the processor model?
-
Gustavo Mendes Hi Gustavo, the machine has 2 x Intel Xeon Gold 6154, 96gb RAM, Nvidia Quadro P4000.
-
Silas Dominey A few things to keep in mind, please turn off HyperThreading and Numa in the BIOS. Numa makes a huge difference in performance when it's on. HT will give you a smaller boost, but we only use physical cores when processing.
Please update these settings first if you haven't, then let us know about your results.
-
Gustavo Mendes HT and NUMA are both turned off, as mentioned in the original post.
-
Silas Dominey Sorry about that, I didn't read it properly, it seems... I did some tests on my end and all cores are being used. Can you do a screengrab of your Rendering tab in the Preferences windows?
-
Gustavo Mendes No worries, I appreciate your help!
I actually think I've gotten to the bottom of it (kind of). The way I had it set up was 2 Flicker effects, one doing Global RGB for dealing with general luminance and splice fixes. and one with just local LUMA (i.e. Global turned off by setting the Temporal Window to 1). The reason I did it this way I so I can Matte Paint out the ghosting from local while still having a relatively stable image underneath it.
When I add something in between the two Flicker effects in the stack, the performance jumps back up to a much higher level (more like 70-80% utilisation). This even works with a GPU layer like Pan and Scan, or an empty Blur layer that I've forced to cache. It seems to me there's some interaction between the two Flicker effects that was bugging the rendering process somehow.
In any case, here's the render tab, I've been experimenting with setting render tile threads to 1, 4 or 6, but it doesn't make much difference.
And here's task manager while it was rendering the local Flicker. It does seem to be using all the cores, just at a very low level.
-
Silas Dominey I'm going to check with my colleague Björn so we can give you more info about it. In the meantime, I'll leave here the description of each of the Rendering settings:
- Render Frame Threads: The number of threads we use to render frames; should be set as close to the number of physical cores as possible. Leave around 2 cores free for Windows tasks
- Render Tile Threads: Splits images into parts and works on them simultaneously. It's only significant when doing high-resolution projects. Set it around 4 to 6 for best results.
- DVO Threads: Number of threads used to render DVOs. Like Render Frame Threads, it should be set as close as possible to the number of physical cores. Leave around 2 cores free for Windows tasks.
- IO Tile Threads: Used for IO operations. Like Render Frame Threads, it should be set as close as possible to the number of physical cores. Leave around 2 cores free for Windows tasks.
- IO Queue Threads: Manages the queues of what frames are handled next. The value here should be 10% of the number of cores.
- Memory Pool: How much memory is allocated for handling images internally, like caching. It's very dependent on source image size and project resolution; for SD projects, we recommend lower values ( around 2048 to 4096) but, in general, the first run will set the proper amount. Always keep an eye on memory usage using Task Viewer, if it gets close to the max amount of memory, lower the value in Nucoda/Phoenix
-