Skip to main content
Marc6285643
Marc6285643
Participant
July 22, 2023
Answered

Blend modes cause 100% GPU usage

  • July 22, 2023
  • 6 replies
  • 436 views

There appears to be an issue with blend modes causing 100% GPU usage. It’s been occurring for a number of months and across a number of Premiere Pro build. However, I’ve spent a number of days trying to track this down and believe I have ruled out GPU drivers and other systems specs as the cause.

The issue is easy to reproduce, place 2 x 1920 x 1080 at 23.976 clips on the time-line, one above the other and chose a blend mode on the top clip. During playback, the GPU will hit 100% and frame skipping will occur.

 

Windows 10 Pro - 22H2 - 19045.3208

Premiere Pro 23.5 build 56

AMD RX 6700 XT (Adrenaline 23.7.1)

AMD Ryzen 7950X

64GB DDR5 - 6000 CL30

2TB M.2 Samsung 980 (latest firmware)

 

I 've tried a number of GPU driver builds, both Adrenaline and Pro, all whql certified and the issue is consistent across all driver builds.

This topic has been closed for replies.
Correct answer R Neil Haugen

Blend modes, by their very nature, are serious resource hogs. The computer has to play both streams of video, with whatever effects are in use added in "live", then play compute the two streams against each other, according to the mode chosen, to come up with the displayed image.

 

It's rough with two streams of intraframe, and totally nasty with interframe.

 

"Intraframe" ... like ProRes, any DNx or Cineform, means that every frame is complete in and of itself. No other frames need be computed to display the current frame. There may be some compression involved, but again, only on the one frame.

 

"Interframe" ... H.264/5 or "HEVC" ... is very different. There is an "iframe" ... a complete frame, and (often) heavily compressed ... every say 9 to 30 some or more "frames" of the video clip.

 

In between iframes are p, b, and ... another that I can't remember at the moment ... "frames". But they aren't really frames. They're only data sets  ... charts of pixel locactions that a) have changed since the last iframe, b) will change before the next iframe, or c) ... both. 

 

So in order to display most frames, the computer has to find the one or two needed iframes, the needed and relevant data sets, and compute what the "current" frame should look like.

 

In other words, to display one current frame, it may have to find, correlate, and decompress the data of up to 35 or so other frames. 

 

The cameras have specialized chips designed to do the process, and every flipping camera has it seems a slightly different chip design. Many computers do not have the chip to essentially reverse engineer the media "by hardware" ... so the CPU and perhaps GPU have to handle this via software processes.

 

Some computers, mostly the Intel rigs with "QuickSync" in their CPUs, and some GPUs, have the bits to handle H.264/5 processing and do mostly ok with it. Many don't.

 

And ... the long-GOP .264/5 stuff is nasty stuff. I work for/with and teach pro coloristis, who all have machines that make mine (24 core Ryzen, 128GB of RAM, 2080TI, 8 internal SSDs including two Nvme drives) ... look positively amateurish anemic.

 

Most of them take any job that includes any long-GOP media, and immediately transcode those clips for use in grading. To typically ProRes or DNx. As part of their 'conform' process.

 

Neil

6 replies

Marc6285643
Marc6285643Author
Participant
July 23, 2023

Hi Neil,

 

Thank you for such a detailed explanation! I've just tested both ProRes 422 HQ and DNxHQ and neither are maxing out my GPU during blending.

 

I stacked 4 x 1080P clips on top of each other, each blending with the one below it. My CPU and GPU were in single digits usage! I tried really pilling on the pressure by adding a load of effect to each clip and I got bored at 38% GPU usage 😄

 

ProRes is the way to go it seems. I wasn’t aware that H264 was a distribution codec and ProRes and DNx are capture and editing codec. I can see that disk space is going to be my next problem! 🙂

 

Thanks again.

R Neil Haugen
R Neil HaugenCorrect answer
Legend
July 23, 2023

Blend modes, by their very nature, are serious resource hogs. The computer has to play both streams of video, with whatever effects are in use added in "live", then play compute the two streams against each other, according to the mode chosen, to come up with the displayed image.

 

It's rough with two streams of intraframe, and totally nasty with interframe.

 

"Intraframe" ... like ProRes, any DNx or Cineform, means that every frame is complete in and of itself. No other frames need be computed to display the current frame. There may be some compression involved, but again, only on the one frame.

 

"Interframe" ... H.264/5 or "HEVC" ... is very different. There is an "iframe" ... a complete frame, and (often) heavily compressed ... every say 9 to 30 some or more "frames" of the video clip.

 

In between iframes are p, b, and ... another that I can't remember at the moment ... "frames". But they aren't really frames. They're only data sets  ... charts of pixel locactions that a) have changed since the last iframe, b) will change before the next iframe, or c) ... both. 

 

So in order to display most frames, the computer has to find the one or two needed iframes, the needed and relevant data sets, and compute what the "current" frame should look like.

 

In other words, to display one current frame, it may have to find, correlate, and decompress the data of up to 35 or so other frames. 

 

The cameras have specialized chips designed to do the process, and every flipping camera has it seems a slightly different chip design. Many computers do not have the chip to essentially reverse engineer the media "by hardware" ... so the CPU and perhaps GPU have to handle this via software processes.

 

Some computers, mostly the Intel rigs with "QuickSync" in their CPUs, and some GPUs, have the bits to handle H.264/5 processing and do mostly ok with it. Many don't.

 

And ... the long-GOP .264/5 stuff is nasty stuff. I work for/with and teach pro coloristis, who all have machines that make mine (24 core Ryzen, 128GB of RAM, 2080TI, 8 internal SSDs including two Nvme drives) ... look positively amateurish anemic.

 

Most of them take any job that includes any long-GOP media, and immediately transcode those clips for use in grading. To typically ProRes or DNx. As part of their 'conform' process.

 

Neil

Everyone's mileage always varies ...
    Marc6285643
    Marc6285643Author
    Participant
    July 23, 2023

    Thank you Remote and Neil for commenting. I'll respond to both of you in one post.

     

    I have been using Premiere Pro for around a year and I've only recently started using blend modes for a specific project, over the last few months. There's been a few new builds of Premiere Pro over that time, all behave the same GPU and blend mode wise.

     

    My workflow would have to change to accommodate non-H264, which I am open to if needs be. DNx/ProRes/Cineform have been mentioned, which codec would you recommend?

     

    The reason why I have reported this is a bug is, the GPU usage seems unusual compared to other workloads/effects I have used without issue.

     

    Colour correction, noise and tracking masks all hit the GPU but low double-digit usage, if that. For example. One of the workloads I used recently was 4 layers of 1080P H264, with 6 tracking masks, position and scale changes, which scrubbed and played back without any frame drop or excessive GPU usage (not render needed). The only time I’ve had to render clips, if when I apply a speed change with optical flow. Warp stabilise also plays back fine, once the analysis is completed.

     

    Seems like a blend mode bug unless blend modes are seriously expensive resource wise?

    R Neil Haugen
    R Neil Haugen
    Legend
    July 22, 2023

    I think having a non-Intel (no QuickSync) CPU there and using two 1080  streams of H.264 ... then throwing in blending modes, which are a heavy "cost" effect ... is simply running that system past available resources.

     

    As noted by "Remote", you may need to try ProRes/DNX/Cineform as either proxies or t-codes and see how that plays. I would suspect with that system that two 1080 streams of the normal editing codecs listed above, then 'blended', will play back much smoother.

     

    In my experience, typically using machines that ain't near "heavy iron" status, I've needed to stick with intraframe codecs as much as possible. And even then, when doing muliptle tracks and throwing in heavy effects (color, warp, video noise reduction, time changes, blend modes ... ) that I've at times completed one step, like Warp, then done a complete Render & Replace to get a new intraframe clip with that effect "done" prior to doing further work.

     

    Neil

    Everyone's mileage always varies ...
      Remote Index
      Remote Index
      July 22, 2023

      Hello marc etc.,

       

      Another way of describing your issue is that blend modes require rendering for playback in your timelines. Perhaps someone with more knowledge than I will chime in, but this doesn't surprise me. (My experience being that these effects have always been pretty demanding and never optimized in any way in Premiere Pro).

       

      Has it been the case that blend modes have not required rendering for you in past? If so, which versions and with which codecs?

       

      Personally, I avoid using H264 media (or any kind of interframe compression codecs). I believe the playback decompression happens all on the CPU so should not really be a factor here (but I could be wrong). In any case, my first impulse is to eliminate this as a factor and try the same effects with more editing friendly codecs (like DNx or ProRes).

       

      R.

       

       

      Marc6285643
      Marc6285643Author
      Participant
      July 22, 2023

      Just to add to this.

      The video clips i'm using are H264 4:2:0 8-bit

      It doesn't matter what blend mode you choose, I tend to use 'screen' however

      Terms & ConditionsAccessibility statement
      Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices