Please help me find my bottleneck...

System in specs.. DR 17.4.2 I think (can't check mid-render it seems).
Doing a render of a 7min 6K video with:
- Spherical Stabilizer
- PanoMap
- Deflicker
applied. No colour grades or other functions.

Am at 55% after 2hrs with estimated time remaining 1h48mins which is consistent at least. But I can't see anything maxed out that would be causing a blockage.

It's a 7min. video. Yes it's "high" resolution and the Spherical Stabilizer is heavy. But this would be 24hrs for a 90min clip, that can't be right with this hardware. Otherwise no-one could ever finish a movie

7 minutes.

CPU is sitting at ~50% across the 32 cores, though I've seen it sitting at 30% at times or getting up to 70. Network card reading the source files is a 10Gbs NIC and is sitting at 30Mpbs. Link (+storage) is capable of 600MB/s at full copy.
GPU levels:
3D: 11%
Copy: 8%
Encode: 0%
Cuda: 0%

Temperatures are all around 60°C and CPU is running at its normal 4.0-4.4Ghz so pretty sure it's not a throttling question either.

So what is DR doing that's not taking full advantage of the hardware here?

CPU is sitting at ~50% across the 32 cores, though I've seen it sitting at 30% at times or getting up to 70.

My guess is that really means half your cores are at 100% and half are not doing anything. Look at the load per core.

CPU is sitting at ~50% across the 32 cores, though I've seen it sitting at 30% at times or getting up to 70.

My guess is that really means half your cores are at 100% and half are not doing anything. Look at the load per core.

No unfortunately, when process manager was saying 48%, most cores were 38-52% while one or two cores were at 78%. Another time all cores were sitting at between 20 & 30%.

Which codec are you rendering into?

Try bypassing the network drives, work locally.

Report back.

Which codec are you rendering into?

Well, this is H264 source encoding to H264, using ProRes proxy for editing. Previously I was using ProRes end-to-end and then HandBrake to encode the end product to H264 for upload to YT.

Try bypassing the network drives, work locally.

Report back.

Current render 4min28 video. This time no deflicker, but Spherical Stabiliser and PanoMap as before. No other filters or effects.
Working from local PCIe Gen4 SSD.
24% done, 51mins remaining.

Capture1.PNG (74.51 KiB) Viewed 2055 times

Capture2.PNG (67.58 KiB) Viewed 2055 times

Capture3.PNG (65.5 KiB) Viewed 2055 times

cont.

Capture8.PNG (136.17 KiB) Viewed 2052 times

Capture7.PNG (52.87 KiB) Viewed 2052 times

Capture5.PNG (77.68 KiB) Viewed 2052 times

The time is not the critical aspect; the Spherical Stabliser is a hog for sure, that I can understand. But I would really like to see 100% pegged on the CPU and at least some assistance from the CUDA load.

The software uses the resources it needs when it needs them. The only user configurable option here is memory, under Preferences.

I believe the OP is pointing out that there should be SOME limiting resource accounting for the wall clock time. If nothing is pegged 100% then it feels like the operation could go faster. What’s the limiting item?


Sent from my iPhone using Tapatalk

Try to encode to DNxHR or Cineform and check the times.

You think the media encoder is maxed out and is holding everything else up?

I've even seen renders stalling when things got tight. A complex timeline of mine was crashing when set to HEVC and even with DNxHR, but it got finished when choosing Cineform. This was under Windows with a Nvidia 3070 mobile and 8 GB VRAM.

The software uses the resources it needs when it needs them. The only user configurable option here is memory, under Preferences.

Ya I mean 'need' is debatable, right..? There is kinda an underlying assumption in all of computing that things should run as fast as they're able to.. not just mosey along taking their time because they don't "need" to go any faster....

I believe the OP is pointing out that there should be SOME limiting resource accounting for the wall clock time. If nothing is pegged 100% then it feels like the operation could go faster. What’s the limiting item?

Exactly. Simply put, I'm encoding with the CPU, and if the CPU is not hitting 100%, then it is not getting data fast enough to feed it. So something else must be getting in the way.

Try to encode to DNxHR or Cineform and check the times.

Good idea. Have lined up:
DNxHR
HEVC using nVEnc on the 3090
Cineform
HEVC on CPU.

Will post SSs after the fact but so far 30% into the DNxHR the CPU load looks the same as before.
FYI this test is using a 58s sample of the same clip above, h264 source, 30fps. After this test I'll use a ProRes source (still recorded in h264, transcoded to ProRes for editing) and test all the same again.

You think the media encoder is maxed out and is holding everything else up?

That sounds like something that is worth verifying, if only I had a clue how to do that )

I've even seen renders stalling when things got tight. A complex timeline of mine was crashing when set to HEVC and even with DNxHR, but it got finished when choosing Cineform. This was under Windows with a Nvidia 3070 mobile and 8 GB VRAM.

The fact that you *can* even render those 'complex timelimes' using a mobile CPU/GPU puts my above situation into context. Mine is not close to complex, it's a single video track with 3 clips in sequence with just one or two fusion nodes each.

CPU load while encoding DNxHR, first 30%, send 85% completion:

30%:

RenderDNxHR-01.PNG (211.64 KiB) Viewed 1588 times

85%

RenderDNxHR-85.PNG (211.06 KiB) Viewed 1588 times

nVEnc result, 25/85%:

25%:

Render-nVEnc-25.PNG (217.35 KiB) Viewed 1573 times

85%:

Render-nVEnc-85.PNG (163.47 KiB) Viewed 1573 times

I believe the OP is pointing out that there should be SOME limiting resource accounting for the wall clock time.

I don't think that's necessarily true.

At least not in a way that a user can change.

I know from my Premiere Pro days (because the engineers often said so) that it would use the resources it needs as it needs them. Not everything the software did was multi-threaded, or could run on the GPU, etc. So long as your drives are keeping up, the only real way to make things faster was faster hardware.

I have no reason yet to believe that's not the case for Resolve as well.

Cineform result.

25%:

RenderCineform-25.PNG (162.74 KiB) Viewed 1560 times

80%:

RenderCineform-80.PNG (160.74 KiB) Viewed 1560 times

And these are the final render times for the exact same 58s clip.

image_2022-06-25_161437307.png (26.14 KiB) Viewed 1549 times

Seems odd that they would all be about the same, no? esp. since one isn't even the CPU. Definitely points to a delivery issue of some kind.

Not sure what tools are available on the PC but I'd be wondering what system calls Resolve is blocked waiting on and for how long. If the app is not full-on using the CPU then the other thing that takes wall-clock time is being blocked waiting on a system call to finish - or being blocked while another process is running.

Yes that's my thinking too. I will spin up perfmon but I was kinda hoping peeps here would have some insights on what to look for.

For reference, here's what the system looks like when encoding a ProRes clip into h264 using Handbrake..

HBProRes-to-h264-01.PNG (459.47 KiB) Viewed 1409 times

So the finding suggests that the problem is limited to Da Vinci Resolve specifically. I.e. it is not making full use of the resources that are available, while other apps *are* able to do so. Is there expertise here that can help me track down the problem or is it something that only BMD can help with?

Any luck getting a system call wall clock time usage? Don’t think I see that here.


Sent from my iPhone using Tapatalk

System in specs.. DR 17.4.2 I think (can't check mid-render it seems).
Doing a render of a 7min 6K video with:
- Spherical Stabilizer
- PanoMap
- Deflicker
applied. No colour grades or other functions.

I think the problem (off the top of my head) is:

1) H.264 source material
2) three different OFX plug-ins, all of which are demanding
3) 6K timeline resolution

Each of these things are potential bottlenecks. I've seen challanges with Deflicker in particular, especially if it's applied to a long shot.

My solution would be to work entirely in DNxHR (source and render), render-in-place for the really difficult tasks (to a "visually lossless" codec), and then try that. And once you have a finished file, then determine if you need to compress it for final distribution. Worst case, you could stabilize, then deflicker and then do the rest of what you needed to do as 3 separate passes. It's generally true that if you throw enough money and hardware at Resolve, you can push it pretty hard, but there are always limits.

Hi Marc
I think the OP is not asking about a speed problem so much as an MPG problem. He can see that only 50% of his computer’s “gas” is being burned. The rest seems to be just drifting out the tailpipe.


Sent from my iPhone using Tapatalk

Any luck getting a system call wall clock time usage? Don’t think I see that here.

Not sure what you mean by that.. wall clock?

Hi Marc
I think the OP is not asking about a speed problem so much as an MPG problem. He can see that only 50% of his computer’s “gas” is being burned. The rest seems to be just drifting out the tailpipe.

Exactly.. if the system is stretched to limits, can't really complain, it's doing what it can. But if half is just sitting idle, the cycles are wasted..

By wall clock time I mean not just cpu or gpu cycles but actual time. So time spent blocked in a system call waiting for a resource counts.


Sent from my iPhone using Tapatalk

Not sure how to go about illustrating something like that..

But here's a small observation that maybe might spark a connection for someone.. Can see that basically one thread is running at 100% but the others are sitting much more idly around.. as if everything in the stream depends on the output from that other thread. Plausible?

image_2022-07-10_113422582.png (155.59 KiB) Viewed 1143 times

This is what ProcessExplorer tells me.. dunno if that means something to anyone..

image_2022-07-10_114406253.png (112.01 KiB) Viewed 1135 times

image_2022-07-10_114728603.png (20.38 KiB) Viewed 1128 times

image_2022-07-10_221925801.png (112.18 KiB) Viewed 1087 times

On MacOS one can use Activity Monitor to take a Sample of the process you're interested in - in this case Resolve - while it's doing something you want to performance analyze. It'll then produce a log which you can save to a file like the one I've attached here - which samples Resolve during a simple data burn render.

The BMD folks should be able to Symbolicate such a log and see where time is being spent - correctly or otherwise.

I'm not sure what tool on Windows one uses to make such a log - but I'm sure they exist!

So this is interesting.
When generating Proxy Media... it -does- appear to leverage the full resources.

This is in DR 18.0.1 now btw.

image_2022-07-30_030733063.png (62.18 KiB) Viewed 753 times