Brand new computer: Surface Book 2 with i7-8650U quadcore, 16GB RAM, Intel 620 and NVIDIA GTX 1060 6GB VRAM
I've set both Global and Local "High Peformance Graphics" to force dGPU utilization. There is no BIOS option to disable iGPU. Disabling iGPU causes even more problems. WMP and VLC both do not utilize dGPU alone, either, even though I have them set to in NCP.
Tech support said Premiere only utilizes one GPU at a time but I know this not to be true on my system as it was running quasi SLI with around both iGPU and dGPU 24-30% utilized simultaneously.
Started a new project, imported one media file: native GH5 h.264 clip 450Mbps and dropped in a new sequence. Proceeded to playback in both Source and Program monitors. Watching Task Manager, CPU jump to 100% utilization, RAM to around 30% utilization each GPU, and video plays without dropping frames for a very specific time (sometimes it's 5s, sometimes 45s but whatever it ends up being, this remains constant every pause and play cycle) AND THEN the dGPU craters to near zero utilization while the CPU and RAM remain as they were, and the video plays choppy, doesn't recover. Pause play, start over, same result only happens in less time.
Any thoughts on what is happening? I was tempted to say running at or near 100% CPU utilization might eventually cause some overrun/throttling action but why no change to CPU and RAM when this occurs?
This happens with High Quality Playback deselected and 1/8 resolution. Yes, I'm stress testing with 450Mbps h.264 files but that's the point.
Thanks in advance.
Copy link to clipboard
The GPU isn't the issue here, as GPU's do pretty much nothing in de-encoding/de-compressing long-GOP media like that clip. That's totally a CPU/cores/threads/RAM issue.
Jarle Leirpoll notes that his Hp Zbook can work with 8k RED files beautifully, but 4k & 1080 H.264/265 files, no. Because that media isn't stored as complete frames like an intraframe codec is: Cineform, DNxHD/R, ProRes, a number of others. That H.264/265 is stored as "complete" I-frames every 9-30 or more frames apart. In-between it only writes data-sets of the pixels that have changed since the last I-frame, will change before the next I-frame, or ... both in the same data-set.
Specialized chips in the camera can create this stuff fast, and it reduces the size of the file on the card dramatically. It's Hades on the CPU gear to de-encode then de-compress though. The colorists I know, with monster machines way past your rig, don't work H.264 "original" media if they can help it. They proxy or transcode it.
So ... for that media, use the Cineform preset included to make proxies on ingestion. Use the + icon to the far right of the Program monitor control block to drag/drop the Toggle Proxies icon to your control block. When editing, toggle on (blue) to use the proxies for playback, off (gray) for viewing original media for quality.
Hi Neil, thanks for the run down on what is and is not used in the de-encode/de-compression routines. It certainly makes sense on the 100 CPU utilization I'm seeing. There is GPU utilization, nonetheless, and I'm trying to understand why it craters at a specific time, each attempt to playback.
Also, I was hoping someone could clarify why I'm seeing both GPUs being used simultaneously when tech support says PrPro is only supposed to be able to use one...is their a switch in the debug control panel that might force utilization of only the dGPU?
On rigs with built-in graphics chips as well as installed full GPU's, PrPro can be somewhat ... puzzling. What it's supposed to do and what it will do in X situation are not necessarily the same. Especially if you didn't ask for the Video Queue on reaching Adobe tech support, you may well have had someone with a generalist's sheet of situation/responses who had little actual experience with the program itself.
Which is why Product Support Manager Kevin Monahan always suggests asking for that Video Queue. That there's no way you'd know existed if someone didn't tell you ... how stupid is that?. Ah well.
Within PrPro, the GPU is used for rescaling (in most circumstances) and certain effects. They have added more to make more use of the GPU as sometimes, you're right, that's a lot of computing power sitting there staring at it's toenails. Here's the link to the chart of GPU-accelerated effects:
List of GPU accelerated effects: https://helpx.adobe.com/premiere-pro/using/effects.html
In the Effects panel, the little "lego block" icons at the top right? ... the first one is GPU acceleration: if that one is shown next to any effect, it's GPU happy. (The other two are 32-bit color, and YUV color.)
So ... why PrPro run on a laptop is doing any particular thing this moment can be a joy to sort. And from what's been said on here, PrPro tends to see Surface rigs more as a laptop than a desktop. Even when you've got some pretty decent hardware in it, like those specs.
Still ... the thing here is that is hellaciously difficult media to de-encode/de-compress. Long-GOP at 450Mbps ... yowza. (And I want one of those cameras myself, btw ... )
So ... at least use the Cineform proxies, and forget trying to use the original media for playback, or do full transcodes to say Cineform (which auto-scales itself for bitrate, kinda cool) or DNxHD/R and then dump them after completing the project as you can always recreate from the original (and vastly smaller) media.
Stan, the biggest takeway from your post is the Video Queue. Just last night I was planning to ask this very same question to the group, how do you get beyond the tier 1 support that generally are only capable to stay on script. I went through 3 Chats and 2 Calls with Adobe Premiere Pro Support and they all ended the same, "I can escalate this call to my supervisor if you would like and they will get back to you in 24-48hrs"... Up to 2 days for a resolution? Only 1 supervisor in the Call Center? And the biggest problem I see with that is their supervisor is only going to have a little more experience than they do. I'm tired of these guys remoted in to my system and wasting an hour of my time each only to say the've done all they can and don't know where to go.
So I gather I need to call in, eh? I'll do that next. If there is a different method or phone number to use to get to them please chime in for my benefit as well as anyone else reading this thread. I'll do the same if I'm successful. Thanks again.
Sorry, mean "Neil" but also thank you to Stan for the other link
Figured that out. The "help" situation can even be frustrating to some of the help staffers. Sigh.
I just saw recent posts on a similar problem, and one solution is to disable OpenCL support for the Intel UHD Graphics in the Windows registry. You see, by default OpenCL support is enabled for both the Intel graphics and the discrete GPU - and that might have been found to cause conflicts within Premiere (in this case, having OpenCL support for both GPUs enabled would lock Premiere to the software-only mode with no hardware GPU acceleration). And then, all Windows versions of Premiere have OpenCL support disabled for Nvidia GPUs, leaving only CUDA or software only as options.
Could you share the link or at least title of that other thread? Sounds like something to try but not finding the discussion. Thanks.
I've been busy compiling clips for educational purposes using the Surface Book 2. These are not 4k videos, but are complied from a large variety of sources. I can now say the SB2 is a decent machine for this kind video editing to/at HD quality.
There is one issue which I am still concerned about, that being screen capturing of videos without dropping frames.. I've found workaround. but not as good as it should be.
Regarding the use of NVIDIA's GPU 1060, this is an issue I hope will be discussed with 2nd level Microsoft technician tomorrow.
At this time I've been able to get the 1060 working at about one-third to what Intel's does simultaneously, by selectively allocating the 1060 to the specific video editing program, including Adobe PR.
Now that I'm over an exceptional high work load I expect to run more tests.