The old issue of slower playback again in 16.1 Betas

As with several previous releases (some 14 Betas mainly), the playback speed on the Color page is suffering tremendously by engaging scopes in Resolve 16.1

I'm sure the devs already know by now where to look to improve it I was getting full UHD@50p through the late 15 betas, the 15 and then all the 16 Betas until today, when it is stuttering again.

Piotr

Try deselecting "use GPU for scopes" in preferences.

Unfortunately it doesn't help at all, John.

Could anyone from BMD chime in, please? Particularly Mr. Rohit Gupta, with whom I had a good PM exchange on the same problem when it first appeared in Resolve 14.x betas; Rohit was then kind enough to provide me with an experimental internal build where the issue was solve completely. Ever since then, as the solution was implemented, all consecutive Resolve releases were problem - free - until now, when the 16.1 Beta version maxes at some 46-48 fps for my UHD@50p projects. Even though my 2 GPUs have been upgraded from Titan to RTX 2080 ti in the meantime...

Rohit, what's your word on it, please? Regards

Piotr

Just decided to check the previous version - Resolve 16 (non-Beta; Build 16.0.060) - and this one runs smoothly just like all the previous Betas of R16 - with full and solid 50 fps in UHD@50p projects... So I can now officially confirm:

- there is a serious playback problem in Resolve 16.1b1 (Build 16.1.17.0)
- this time, the slow-down has nothing to do with Scopes being On in the Color page; the issue is present in all pages

Back to Resolve 16 final for me...

Piotr

Hello,

Has anyone compared the preformace of the final 16, and the 16.1b1 versions of Resolve and can (or cannot) confirm my findings on severe regression in achievable playback speed in the latter?

I realize some of you can be bored by now with my often reports on this important aspect of editing experience - but believe me, with majority of my projects being UHD@50p AND comprise coverage of classical music performances, the Resolve's ability to play back fluently and always in full speed is absolutely essential considering my projects are MC (multi-camera, 6-10 angles) plus the very nature of classical music coverage requires extremely precise cuts (angle changes) AND perfect A/V synchronization - I hope you will forgive my posts being so often related to the projects' playback speed.

At the current state, version 16.1b1 is unusable for my purposes - reverting to the 16 which is OK.

Also - any word from our BMD Support friends present on this Forum? TIA,

Piotr

I shoot everything at 24. I can test if you care to upload some footage for download.

[Rohit Singhal]

Hi Piotr. Can you please post your project and captured logs from your system?

Just to let you know, dear BMD Developers, that the 16.1 Beta 2 is slow on playback just like the Beta 1 was; back to the Release 16 which has been the last one capable of normal (i.e. full speed) playback of my UHD@50p projects.

Sorry, but some one-way route has been taken with programming; both 16.1 Betas are only capable of some 44 fps.

Piotr

Just to let you know, dear BMD Developers, that the 16.1 Beta 2 is slow on playback just like the Beta 1 was; back to the Release 16 which has been the last one capable of normal (i.e. full speed) playback of my UHD@50p projects in the Color page.

Sorry, but some one-way route has been taken with programming; both 16.1 Betas are only capable of some 44 fps.

Piotr

What are you doing to your footage? Short of TNR, your hardware should haveave no problems with uhd footage.

Just to let you know, dear BMD Developers, that the 16.1 Beta 2 is slow on playback just like the Beta 1 was; back to the Release 16 which has been the last one capable of normal (i.e. full speed) playback of my UHD@50p projects in the Color page.

Sorry, but some one-way route has been taken with programming; both 16.1 Betas are only capable of some 44 fps.

Piotr

What are you doing to your footage? Short of TNR, your hardware should haveave no problems with uhd footage.

Exactly. Add to it all is still fine with pre-16.1 releases, and we have a proof of some nasty bug in both 16.1 Betas.

Piotr

Will you post your capture logs and project so that the developers can have a look?

From earlier:

"Can you please post your project and captured logs from your system?" - Rohit

@Piotr,

My sense is that work is being done "under the hood" in 16.1 betas to improve playback. Certainly seems to be changing for my low level AMD card. May be related to hardware acceleration - see setting in preferences. You could try changing that.

[Rohit Gupta]

We are not seeing this issue here. One of the things to check is that OpenGL is running on the GPU connected to the display. One easy way to check this is to move your monitor to your 2nd GPU. (You control this in NVIDIA control panel)

The other way to troubleshoot this is to remove one of your GPUs and check.

Doesn't explain why 16.1 is different from 16.0 though, but we don't see the problem here.

Gentlemen,

Thanks for offering solutions, but nothing works. Of course I tested thoroughly, and both GPUs work as they should. And yet - no more than ca. 45 fps in 16.1 Betas...

I'd like to remind you I have already pin-pointed a similar issue with several 14 Betas, but it was corrected by BMD Team after I drew Rohit's attention to it. I'm not saying it's the same issue (with the 14, the slowdown only occurred in the Color page with scopes active; in the 16.1 - all Pages are affected, no matter whether scopes are on or off).

Sorry - these are hard facts. I also see no point in sending my logs etc. as everything is configured exactly the same in 16 and 16.1.

Piotr

Sorry - these are hard facts. I also see no point in sending my logs etc. as everything is configured exactly the same in 16 and 16.1.

Piotr

I think you still should send your project and the logs as they cannot reproduce your problem. If you want to get it fixed and you have the developers attention the best you can do to send him what he needs.

Rohit,

Is it possible the beta versions containing more debug information which might cause these slowdowns and they are not in the final?

Since Rohit demanded it - even though I personally can't see how it could help - here is the link to my 16.1 Beta 2 crash logs:

https:/mega.nz/#F!NZZExCgY

Please add the second missing forward slash after https. Thanks,

Piotr

PS. Moving my system monitor to the other GPU doesn't change a thing, just like configuring the nVidia's settings (BTW, please help me make sure I did the latter correctly).

We are not seeing this issue here. One of the things to check is that OpenGL is running on the GPU connected to the display. One easy way to check this is to move your monitor to your 2nd GPU. (You control this in NVIDIA control panel)

The other way to troubleshoot this is to remove one of your GPUs and check.

Doesn't explain why 16.1 is different from 16.0 though, but we don't see the problem here.

Dear Rohit,

Could you please elaborate why should a version of Resolve run better with monitor on my 2nd GPU, while another version doesn't care for that?

Thanks

Piotr

Dear Rohit,

Could you please elaborate why should a version of Resolve run better with monitor on my 2nd GPU, while another version doesn't care for that?

Thanks

Piotr

Just to be clear he wasn't suggesting that it would run better, at least how I read his comment. As I read his comment he suggested swapping gpu as a test to see if OpenGL is running correctly.

One of the things to check is that OpenGL is running on the GPU connected to the display. One easy way to check this is to move your monitor to your 2nd GPU. (You control this in NVIDIA control panel)

As an aside, it's a good chance the issue is driver related. Nvidea and AMD have both been rushing driver updates out the door for the last few years.. In some cases it's to fix bugs, in others to add and remove features. It's all gotten rather messy, and caused a lot of problems for developers and end users.

for example read this about How Nvidia drivers decreased performance for a little while earlier in the year. Note the bolded part.
https://www.pugetsystems.com/labs/suppo ... IXED-1376/

Summary of issue
In some of our recent testing, we noticed that we were getting much lower benchmark scores in DaVinci Resolve compared to what we have seen in the past. After trying multiple versions of DaVinci Resolve Studio (ranging from 15.0 to 15.3), multiple hardware platforms, and many other troubleshooting steps, we discovered that the issue was being caused by recent NVIDIA GPU drivers.

In particular, we found that the following drivers are causing 11% lower FPS on average in the Color Tab, although in some cases the performance drop was as large as 20% depending on the codec and grade. The NVIDIA drivers that we have confirmed to have this issue are:

418.81 - Released Feb 04, 2019
418.91- Released Feb 13, 2019
419.35 - Released Mar 05, 2019
Note that while we have confirmed it with these driver versions, the issue will likely be present with future driver releases as well until NVIDIA, Blackmagic, or Microsoft (depending on where the root of the issue is) are able to implement a fix.

We have confirmed that this issue occurs with NVIDIA's GeForce RTX line of cards, but have not tested it with the older GTX series. It appears to be fairly universal in terms of what codecs are affected including H.264, DNx, ProRes, BRAW, CinemaDNG, and RED footage.

I'd also assume that because you are running dual cards you are even more susceptible to driver issues, as the manufactures have been pushing users towards one powerful card instead of two lesser ones.

With all due respect to the OP, if the development team of a piece of software you are having an issue with requests something from you that they need in order to fix your issue, GIVE IT TO THEM. If they request that you reconfigure your system and report the results, DO IT.

I've been working with software developers on many projects for 25+ years, and I have never seen a problem fixed in a timely manner when the individual with the issue refuses to hand over the very information needed to figure it out simply because they didn't think it will help. What else can they do? Short of requesting you box up your system and mail it to them, they can only rely on the mechanisms they designed into their software to provide them with as much debug info as possible to figure out what's going on. There is a TON of useful information in those logs that allows them to see what Resolve is loading, settings Resolve is using, and things you are doing in Resolve that will help shed light on what's happening without you having to mail your system to them.

And in my years dealing with development teams, BMD is one of the most proactive and responsive teams I've encountered, sometimes responding withing MINUTES to issues. Imagine if this were just a user forum with thousands of complaints/concerns/criticisms that BMD ignored, blew off, or never saw? (TBQH, this is one of the reasons I am now a BMD fanboy. I'm not going to mention any names, but the cameras I no longer have an interest in failed me outside of the hardware they developed, but by other behaviors, like ignoring/abandoning/lying to their customers. Could I get a slightly better camera from another vendor for 10 times the price? Sure I could, but I don't.)

Trust me, I've been at the crap end of a Resolve bug more than once. I've lost many hours to working around problems. I've had to roll back several times. I've missed deadlines because of corrupted projects, etc. But I've never expected BMD to fix any of it in the dark.

I hope others who aren't familiar with software development on this forum understand this so other issues get addressed in a timely manner. Its pretty frustrating to a development team when there is a known bug floating around that they can't reproduce in the lab and those with the problem refuse to help solve it.

Again, with all due respect, I realize you eventually provided them the info, but I see this a lot around here and its just counterproductive and in some ways has to be demoralizing to the staff at BMD.

I really do hope your issue gets fixed in B3.

With all due respect to the OP, if the development team of a piece of software you are having an issue with requests something from you that they need in order to fix your issue, GIVE IT TO THEM. If they request that you reconfigure your system and report the results, DO IT.

I've been working with software developers on many projects for 25+ years, and I have never seen a problem fixed in a timely manner when the individual with the issue refuses to hand over the very information needed to figure it out simply because they didn't think it will help. What else can they do? Short of requesting you box up your system and mail it to them, they can only rely on the mechanisms they designed into their software to provide them with as much debug info as possible to figure out what's going on. There is a TON of useful information in those logs that allows them to see what Resolve is loading, settings Resolve is using, and things you are doing in Resolve that will help shed light on what's happening without you having to mail your system to them.

And in my years dealing with development teams, BMD is one of the most proactive and responsive teams I've encountered, sometimes responding withing MINUTES to issues. Imagine if this were just a user forum with thousands of complaints/concerns/criticisms that BMD ignored, blew off, or never saw? (TBQH, this is one of the reasons I am now a BMD fanboy. I'm not going to mention any names, but the cameras I no longer have an interest in failed me outside of the hardware they developed, but by other behaviors, like ignoring/abandoning/lying to their customers. Could I get a slightly better camera from another vendor for 10 times the price? Sure I could, but I don't.)

Trust me, I've been at the crap end of a Resolve bug more than once. I've lost many hours to working around problems. I've had to roll back several times. I've missed deadlines because of corrupted projects, etc. But I've never expected BMD to fix any of it in the dark.

I hope others who aren't familiar with software development on this forum understand this so other issues get addressed in a timely manner. Its pretty frustrating to a development team when there is a known bug floating around that they can't reproduce in the lab and those with the problem refuse to help solve it.

Again, with all due respect, I realize you eventually provided them the info, but I see this a lot around here and its just counterproductive and in some ways has to be demoralizing to the staff at BMD.

I really do hope your issue gets fixed in B3.

Out of respect to the great BMD Developers, I have put the link to my logs in a post above yours - i.e. before you reminded me to do so. Thanks anyway

Piotr

Rohit also asked for your project, Piotr - might help - you never know.

[Rohit Gupta]

Can't seem to download your logs. Needs a password of some sort.

Can't seem to download your logs. Needs a password of some sort.

Sorry Rohit - indeed, I copied the wrong version of the link which indeed requires a key. Here is one that should give you access to the folder without any further actions:

https:mega.nz/#F!NZZExCgY!KC2SS24sEMkhia3AdrI_jQ

Again - please add the two missing forward slashes after "https:". Sorry for your trouble,

Piotr

[Rohit Gupta]

Just to keep you posted, the issue is related to a Preferences setting:

Delay viewer display by … frames

We'll see if we can handle it more optimally in the future.

Just to keep you posted, the issue is related to a Preferences setting:

Delay viewer display by … frames

We'll see if we can handle it more optimally in the future.

Thanks, Rohit. Does it mean it's handled differently in the 16.1 than before? Which value should I set it for?

Regards
Piotr

Dear Rohit,

I have had a long break in my Resolve work, and only now started to experiment with the 16.1 slow-down/stuttering issue. This fresh look helped me establish the following:

1. The best results (almost full 50 fps, still a little audio stuttering) I'm getting with Delay viewer display by 0 frames

2. The issue seems to be confined to just a single clip in this particular timeline; it happens the clip is also the only one with the Light Rays OFX filter (see viewtopic.php?f=21&t=96706)

Does the said filter differ from the others in that it could be the reason for such behavior? Please mind you it also was the case in releases prior to the 16.1, as per my other thread I'm posting a link to)?

Thanks and Regards
Piotr