v16.2.7 + v17 - Data Burn-in Massive Render Performance Hit

v16.2.7

Did a quick search and didn't see any thread on this before.

Rendering out a few projects with burn-in for others to review I was hitting about 50-55 fps rendering to 1080p/24.

The exact same clips with the exact same MP4/h265(Nvidia) settings with data burn-in turned off saw render speed jump to 95fps.

Both CPU and GPU utilization were significantly lower when burn-in is enabled and subsequently jump up when burn-in is disabled. It's as if when burn-in is enabled the GPU seems to be ignored or disabled and the entire render action is CPU-based. But even then, the CPU is not fully taxed. Nothing is, really. CPU, GPU, HDD(source or target) as well as system memory are all nowhere near max load.

If this is not a known issue then be aware that your test renders are going to take almost twice as long to spit out but your finals won't.

I don't know about v17, I won't be running it until its public release. Been stung by the beta version gotcha with support in the past.

Anyone else see this happen to them as well?

Tested with Studio 17b6 for Windows. I saw no difference.

Cool, so maybe that's fixed in the v17 track!

I have experienced the same behavior in 17b6 and 17b7.

With Data Burn-in turned off I get ~320fps render speed transcoding to H.264 with NVENC on an RTX 3090. With Burn-in enabled I only get ~75fps, everything else being equal.

While using burn-in, I see my CPU usage drop significantly, with only 2 of 64 available threads heavily (not fully, at approx. 75%) loaded, 2 more modestly loaded (approx. 40%), 2 more lightly loaded (approx. 25%), and all the rest are just chilling (approx 15% or below 10%). GPU utilization stays around 22%.

But as soon as I turn off burn-in, the GPU usage spikes up to above 90%, and CPU is almost twice as loaded.

I always turn on burn-in when I transcode all the rushes to proxies for editing over NAS so that I can have a reference during re-conform.

That turning on data burn-in slows down my transcode by 76% is a huge problem for my workflow.

Hmmmm, so it hasn't been addressed in the v17 stream!!

I ran the test again in Studio 17b7 for Windows.

I found no difference using the Native encoder (my preference for deliverables).
I found a 40% drop with Burn In enabled using the nVidia encoder.

I've filed a case with BM about this.

I suspect that when Burn-In is enabled, the NVENC encoder can't be used so even though it's selected in the render settings, it gets bypassed and the setting ignored.

I hope that this is not the case or if it is, it can be fixed. NVENC encoding saves an enormous amount of time.

I tested again transcoding braw from Pocket 4K to DNx (so that NVENC becomes irrelevant).

With burn-in on, I get ~60fps speed, and with burn-in off, I get ~280fps.

Again, CPU usage is low when burn-in is on vs. when it's not.

It seems that the burn-in cannot utilize multiple threads effectively. The encoder has to wait for the burn-in to do its job before actually encoding, and if burn-in can't leverage the threads available, it'll become the bottleneck, regardless whether the encoder is using NVENC or not.

I tested again transcoding braw from Pocket 4K to DNx (so that NVENC becomes irrelevant).

With burn-in on, I get ~60fps speed, and with burn-in off, I get ~280fps.

Again, CPU usage is low when burn-in is on vs. when it's not.

It seems that the burn-in cannot utilize multiple threads effectively. The encoder has to wait for the burn-in to do its job before actually encoding, and if burn-in can't leverage the threads available, it'll become the bottleneck, regardless whether the encoder is using NVENC or not.

Whoa, awesome catch. I didn't think of testing without the GPU in play at all. I just assumed it was a GPU rendering issue. That what you get when you assume!

suspect that when Burn-In is enabled, the NVENC encoder can't be used so even though it's selected in the render settings, it gets bypassed and the setting ignored.

I'm skeptical of that explanation because I still get significantly faster performance using nVidia over Native, even with Burn-In enabled.

Dalavi Tang's post seems more plausible now that it's a threading issue with Burn-In data creation.

Reply from support

That's just the way it is currently. Dev team has plans to improve burnin performance in the future, but today, it is what it is.

Good to know.

How much of a difference do you see? It's less than 10% here for ProRes encoding and 13% for H.265.
Not negligible, but neither huge. But then, I have lesser hardware.

I saw a 40% drop with Burn-In enabled exporting from H.264 to H.264 using a GTX 1070 (8GB).

s per Dalavi Tang earlier in the thread, he's seeing a 75% drop in rendering perf.

With Data Burn-in turned off I get ~320fps render speed transcoding to H.264 with NVENC on an RTX 3090. With Burn-in enabled I only get ~75fps, everything else being equal.

I myself went from 95fps to around 50fps