GPU decoding misbehaving (16.1-b1)

I just bought an nVidia GTX 1070 card with 8 GB VRAM. I installed the card along the latest 431.70 Studio driver on latest Win10 & Intel Xeon E5-1620 v3 @ 3.50GHz.

I played back on Resolve 16.1-b1 several HD & 4k h.264 8bit 4:2:0 files and h.265 10bit 4:2:0 files. These are formats that this graphics card can decode in hardware, I checked before buying.

While playing them back, I was watching the Task Manager's Video Decode graph.

SOME times the hardware decoder would kick in, and some other times it would NOT. It felt arbitrary, but it seems that when h.265 would get hardware decoding, the h.264 clip next to it would NOT. And when after a while, it decided to kick in again, the h.264 clips would get hw decoding, but the h.265 ones would not!

It looks as if the decoding system can't switch from h.264 <-> h.265 on the same timeline. And sometimes, none works anyway, and some fewer times, both work! So odd! Not consistent at all!

In my preferences, cuda/nvidia/gpu are all enabled, and h.264/5 are also enabled for nvidia gpu.

PS. I don't know if BRAW is supposed to also show up in the video decode graph panel on task manager, but it never does (it's checked to use gpu).

SOME times the hardware decoder would kick in, and some other times it would NOT. It felt arbitrary, but it seems that when h.265 would get hardware decoding, the h.264 clip next to it would NOT. And when after a while, it decided to kick in again, the h.264 clips would get hw decoding, but the h.265 ones would not!

Decoding h.264 and h.265 is really quick, I am not so sure you could determine by watching the task manager if all clips are used.

If playback is fine, why look for trouble? And as noted above, these monitors may not be accurate.

Whatever the card can do, the issue is what Resolve supports. Is there GPU-accelerated decoding on 10 bit h.264 and/or any version of h.265?

There is no hw Accel on h.264 10-bit...

I suggest putting clips on different tracks and resizing and repositioning each so that all tracks get rendered. This should force all clips to be hw decoded at the same time, then you disable tracks one by one and see whether video decode graph drops with each disabled track. Also keep an eye on the CPU usage.

Sent from my GM 5 Plus d using Tapatalk

>Also keep an eye on the CPU usage.
>If playback is fine, why look for trouble?

It's not fine unfortunately: when the HW decoding is not kicking in, h.265 decoding takes 100% of the CPU. However, when the HW decoding IS kicking in, it only takes 20% (and about 40% on the GPU).

So I have a good reason to believe that not always the hw decoding kicks in! There is a bug somewhere in the chain! Either Resolve's, or the driver's.

> Is there GPU-accelerated decoding on 10 bit h.264 and/or any version of h.265?

There is no hw Accel on h.264 10-bit...

Yes. There is 8/10/12bit decoding support for 4:2:0 h.265 for my card (I checked before buying). And yes, there is support for 8bit h.264. Which is the kind of clips I used. I didn't use 10bit h.264.

It's not fine unfortunately: when the HW decoding is not kicking in, h.265 decoding takes 100% of the CPU. However, when the HW decoding IS kicking in, it only takes 20% (and about 40% on the GPU).

So how do you actually test this? Right when you open the project?

At any time. I simply let the timeline play. Other times I stop it. Reposition the cursor, and play again. Among these start-stops, the GPU will decode or won't decode in hardware. Completely a crapshoot.

At any time. I simply let the timeline play. Other times I stop it. Reposition the cursor, and play again. Among these start-stops, the GPU will decode or won't decode in hardware. Completely a crapshoot.

Repositioning the cursor could land at the end of a long GOP (H.264 and H.265 usually use heavy inter-frame compression). All prior frames of the clip would have to be decoded before you get to the current frame. Now Resolve can cache decoded frames but obviously not all frames.

Point is that hardware decoding or not, long GOP encodings require extra time for cursor positioning and resizing clips. To avoid this I suggest you use optimized, i.e. intra-frame only, media for effective editing.

I rather not. My card can't do All-i h.265, only long-gop, and I definitely don't want to waste time re-encoding to prores/dnxhd. That's why I upgraded my card, so I can have hardware decoding for long-gop at least.

My feeling is that is not an issue of where the cursor is falling into. It should not matter at all. If it does, then it's a bug or bad architecture of what Resolve is doing. Resolve should strive at all times to offload to a GPU, not only if it's convenient.

If you can discern a pattern, you could maybe help the developers solve this, but other than that, just wait.

I think this area of the code has been seeing a lot of changes lately, and will take some time to get right - I guess it's very complicated and somewhat dependent on what NVIDIA and AMD are doing with their drivers. FWIW, I have had similar strange issues with AMD cards ever since the first version 16 betas.

My feeling is that is not an issue of where the cursor is falling into. It should not matter at all. If it does, then it's a bug or bad architecture of what Resolve is doing.

It totally matters and Resolve is not to blame.
You simply cannot decode a random frame that is part of a GOP sequence, you have to decode many frames and sometimes even all frames.

A 1070 is not that powerful, so it should be easy enough to stress the system to elucidate whether or not this is an actual random performance drop versus a measurement artifact. I certainly agree that the windows performance monitor is not 100% trustworthy.

In my case (AMD Rx580) the various issues are quite obvious and have already been posted here by others. I don't consider this a big deal - it's still in beta after all.

A 1070 is not that powerful

The 1070 is more than enough to decode 8 bit h.264, and it can h.265 just fine too. It has nothing to do with the card, it has everything to do with how the data is send to the card. Also, the Windows panel is consistent: when the gpu is not activated, the cpu is, big time. So it's not a Windows bug. Windows reports it just right.

It's funny how many comments are over here to try to make me sound that I did something wrong, or that I don't know what I'm talking about. The bug (or weak architecture) is real, and it's either Resolve's, or the driver's. And my money is on Resolve.

You simply cannot decode a random frame that is part of a GOP sequence, you have to decode many frames and sometimes even all frames.

It's not "many" frames, it's a few frames. And Resolve could easily send the data to the card starting from the "right" frame before it, and then display the video from the frame the cursor demands of it. Either way, this is something to be fixed, and it can be fixed. Before I became an artist I was a programmer, so I can distinguish between weak code and an "impossibility" as you present it.

It's unacceptable to be buying the Studio version with the promise of hardware accelerated h.264/5, and having it work only "some times". VLC and other players I tried DO NOT exhibit such a behavior.

If you can discern a pattern, you could maybe help the developers solve this, but other than that, just wait.

It's 100% reproducible. All they have to do is put some h.264 and h.265 files on their timeline, let it play, start/stop, reposition the cursor, and watch the graph.

It's funny how many comments are over here to try to make me sound that I did something wrong, or that I don't know what I'm talking about. The bug (or weak architecture) is real, and it's either Resolve's, or the driver's. And my money is on Resolve.

Well it certainly seems to me that your teacup is rather full.

The bottom line is that hardware-accelerated decoding is not the panacea for fast editing of long GOP codecs. The panacea is to use all-intra encodings.

And by the way your GPU should handle all-intra H.264/H.265 just fine, it even hardware decodes it! However, I would still recommend ProRes, Cineform or DNxHx over H.264/H.265.

@Eugenia

I think you should read my post again a little more carefully. I am not disagreeing with you or criticizing you.

But I will reiterate: 1) It is a beta. 2) GPU hardware acceleration is tricky.

@eugenia: I'm on vacation (obviously ) and can't check/test, but have you tried checking "show all frames"?

Also answer to another issue brought in the original post: For BRAW GPU decode confirmaton you need to look at the Compute graph activity...

I think I found the problem. Anything shorter than a 3 seconds h264/5 clip does not get hardware accelerated. Since I do music videos, with often fast cuts, that's not that great. Basically you start with a perfectly accelerated clip, and as you cut, the timeline gets slower. This could be prevented, as we discussed above. "Show all frames" didn't make a difference btw.

Basically you start with a perfectly accelerated clip, and as you cut, the timeline gets slower.

You may cut the clip in the editor, the decoder may have to access many frames before this cut to reconstruct the current frame.

And obviously Resolve cannot cache all decoded frames in memory.
Make the calculation: 1 second of UHD@30p in 32bit float will be about 3GB.

It's not "many" frames, it's a few frames. And Resolve could easily send the data to the card starting from the "right" frame before it, and then display the video from the frame the cursor demands of it.

It might be a hell of a lot of frames depending on how it was encoded. How far apart I-frames are is a configurable option in most encoders, and when they are far apart it can hammer a decoder.


Also, what kind of drive are you working off of?