DR - All Versions - Mono Thread Behavior - Playback Slows

Members of the CSI believe we found an issue in resolve, and wanted to let you know about it. It's fairly easy to reproduce, and seems to be across all versions, on Mac and Linux (I haven't access to a windows resolve workstation).

The steps to reproduce are :
- Create a simple HD project, import a sample Prores HD file (my guess is you can use any media), create a timeline from the Prores.
- Add temporal NR on a node. Only 1 frame is enough, and I've found all of the other settings to be irrelevant. At that point playback should be real-time. Depending on the hardware config, the GPU is working at 30-60% of its capacity.
- Add 40+ nodes (doesn't matter if they are serial or parallel) in the clip node tree or the timeline node tree (it also works with less, but depends on the machine, I've seen the problem happen with 25 nodes). You can let them be, or disable them, both situations work to reproduce the bug.
Once they exist, if you try to play your sequence back, you won't have real time playback anymore.

This issue was a problem to us since our colourists usually work with groups using fixed node trees with ~15 nodes, so 15 in group pre-clip, 15 in clip, 15 in group post clip. So even with relatively simple colour setups that include a bit of NR, we can lose real-time playback even though the processing power required is way less than what the workstation is capable of.

We've tested on v17.1.1, v16.2.[5,6,7,8], and also 12.5.6 (we had a hunch that before then, the NR was working differently) on Linux, and on v16.2.8 on macos. System specs are overkill for playing back with only the NR activated, we can play it back smoothly before adding the nodes.

Last (maybe) relevant info, with the 40+ nodes active, I can see on Linux that there is a resolve process that's running at 100% all the time. If I do a strace on it, I see that it's only opening /dev/urandom, reading a few bytes of it, then closing it, in a loop. When the playback is smooth, the same process is not capped at 100% anymore. It's maybe irrelevant, but that is the only thing that I found interesting while troubleshooting.

Thanks for your consideration in reviewing this issue
And as always, thanks for all your hard work in making DR a great program.

On behalf of the CSI and CSWAG - Dario

+1

I have been able to replicate this issue following these steps. Empty nodes, even nodes that are turned off have an impact on performance.


Sent from my iPhone using Tapatalk

+1

This issue has plagued me and my team at Cheat for years across multiple versions of Resolve. If this can be improved or fixed I would be a very happy boy.

Worth noting that this issue is further compounded by Raw formats, especially Arriraw where the effect is 3-4x worse, so even on a very powerful system it could limit you to only 10-15 nodes before playback drops

+1

+1

+1

+1. Can definitely replicate this behaviour. Please make it a priority to fix BMD, we would really appreciate it!

+1 Same here, Win10 Resolve 17 HP Z640 64giggles 1080 gee tea ex.

+1