Welcome, Guest
Username: Password: Remember me

TOPIC: rMPB export CPU usage

rMPB export CPU usage 09 Jun 2019 00:33 #100169

  • Paul Anderegg
  • Paul Anderegg's Avatar
  • OFFLINE
  • Junior Boarder
  • Posts: 30
  • Thank you received: 3
  • Karma: 0
Installed the Intel Power Gadget, which shows that I am using only 1.8Ghz on my 2.8 (4.0 turbo) 2015 rMBP with AMD when exporting to h264. ProRes exporting bumps that up to 2.2GHz, but still...is this normal? This low CPU usage results in anywhere from 75-100c CPU temps, but remains constant, so doesn't look like throttling. The general CPU usage for anything never exceeds 75%.

For reference, exporting 8 minutes of XAVC 10 bit 422 720p60 to h264 took 3 minutes, so not like the Mac is bogging down, but the 1.8GHz CPU during export baffles me. I also don't like how the CPU goes to 100c and the GPU goes to 85C...that's crazy hot.

Paul
The administrator has disabled public write access.

rMPB export CPU usage 09 Jun 2019 12:49 #100174

  • FCPX.guru
  • FCPX.guru's Avatar
  • OFFLINE
  • Platinum Boarder
  • bbalser.com
  • Posts: 2687
  • Thank you received: 351
  • Karma: 33
A process will only use as much CPU resource as it is able, or needs. And some of this exporting is being done by the GPU, and on some Mac's, the built-in H.264 encoder (semi-part of CPU, no clue how it shows up on Power Gadget).

But if your export times are OK, what's the issue? Not every process can use 100% of your CPU, nor should it. Some parts need to be processed before others, in which case they have to wait before they can start. A video is encoded frame by frame, not all frames at once. Especially Long GOP codecs, which jump around a lot and are very intense encoding nightmares, mathematically.

And a laptop has to manage its heat, so it doesn't burn itself up. Thus, depending on the intensity of the process, it may slow itself down, nothing wrong with it trying to not set fire to your house, IMHO.

I don't see anything to worry about. And I think you're over thinking things. CPU usage means absolutely nothing when exporting (transcoding) video files. I believe you're thinking about CPUs in a way they simply don't operate.
The administrator has disabled public write access.

rMPB export CPU usage 10 Jun 2019 12:02 #100188

  • Paul Anderegg
  • Paul Anderegg's Avatar
  • OFFLINE
  • Junior Boarder
  • Posts: 30
  • Thank you received: 3
  • Karma: 0
I guess I was freaking out because I have never seen the CPU temps on a Macbook before, only the 2018 i9 reports of overheating/throttling at 100c, so when I saw 100c, it freaked me out.

Anyone happen to know the whole story about encode speeds with 2018 rMBP's with the T2 chip? I don't quite understand the articles I am reading, making it sound like T2 is like a super Quicksync encoder chip. I tested a new Handbrake built that uses Apples QS VideoToolbox, and was getting 380fps on a 720p60 h264 transcode (successful transcode) speed...on my 2015 non T2 rMBP.

Paul
The administrator has disabled public write access.

rMPB export CPU usage 11 Jun 2019 17:04 #100199

H264 encoding does use the quick sync feature that's build in to the Intel CPU's internal GPU and it is dedicated to encoding/decoding h264 video. Its a chip designed to do just that, faster than a CPU and that's what gives FCPX the speed advantage. The power gadget won't show anything related to this, but istat menus do.

Now, the i9's throttling issue isn't exactly related to the CPU overheating but its due to the VRMs (Voltage Regulator Modules, the parts that feed power to CPU, GPU, RAM etc.) failure to supply enough current to the CPU to sustain max frequency while they also supply current to the GPU.
Attachments:
The administrator has disabled public write access.

rMPB export CPU usage 12 Jun 2019 12:41 #100209

  • joema
  • joema's Avatar
  • OFFLINE
  • Platinum Boarder
  • Posts: 1172
  • Thank you received: 242
  • Karma: 21
Paul Anderegg wrote:
I am using only 1.8Ghz on my 2.8 (4.0 turbo) 2015 rMBP with AMD when exporting to h264. ProRes exporting bumps that up to 2.2GHz, but still...is this normal?

Yes this is normal. H264 is handled by dedicated Quick Sync logic which doesn't show up in Activity Monitor. ProRes output does not require or use Quick Sync so CPU will be higher.

Paul Anderegg wrote:
...Anyone happen to know the whole story about encode speeds with 2018 rMBP's with the T2 chip? I don't quite understand the articles I am reading, making it sound like T2 is like a super Quicksync encoder chip. I tested a new Handbrake built that uses Apples QS VideoToolbox, and was getting 380fps on a 720p60 h264 transcode (successful transcode) speed...on my 2015 non T2 rMBP...

For H264/HEVC encode/decode, there are four classes of Macs: (1) Those without video acceleration such as the 2013 Mac Pro, (2) Those with only Quick Sync acceleration such as iMacs 2011 and later and MacBook Pros before 2016, (3) Those with only T2-based acceleration such as the iMac Pro, and (4) Those with both T2 and Quick Sync such as the 2016 and later MacBook Pro.

Separate from this is encode/decode acceleration on some AMD GPUs -- a dedicated hardware block called UVD/VCE (Unified Video Decoder / Video Coding Engine). Given the right software framework and API support, this also could accelerate video encode/decode. So on some Macs this would be an additional pathway, however I'm not sure it is used by macOS. For example the D700 GPU on the 2013 Mac Pro is really an AMD FirePro W9000, and it has UVD/VCE acceleration. Yet that feature is definitely not used.

There are three layers of published APIs to access this functionality. From more abstract to less abstract: AVKit, AVFoundation, and Video Toolbox. Apple might also use private, undisclosed APIs to access certain features within their own apps.

Each type and version of video encode/decode acceleration varies in capability and performance. E.g, the Quick Sync version on the 2017 iMac's "Kaby Lake" CPU is about 2x faster than on the 2015 iMac's "Skylake" CPU, as used by FCPX.

The T2 encode/decode performance on the iMac Pro was initially slower than Quick Sync on a 2017 iMac, but in late 2018 updates to macOS and FCPX improved this so it's generally equal or faster. However in pure smoothness of playback the 2017 iMac is still faster on some codecs such as XAVC-S. Even the latest versions of macOS and FCPX do not use hardware acceleration for 10-bit HEVC on iMac Pros, only for 8-bit HEVC.

Even though Premiere Pro is generally quite sluggish on 4k H264, on macOS it may be using hardware acceleration for 10-bit HEVC output, whereas FCPX is not. I don't know how Adobe achieved that. The Premiere export dialog says "software" not "hardware" acceleration, but (in this one narrow case) it's six times faster than FCPX, at least on an iMac Pro. This illustrates how complex video hardware acceleration is.

For Macs with only one acceleration type, the relevant API will use that if called correctly and if the media format is compatible. For Macs with two or more acceleration types, e.g, 2016 and later MacBook Pro, I don't know how or if the application layer can specify which hardware is used.

Edit/add: a WWDC 2019 presentation implied it's possible to use Video ToolBox to programmatically interrogate the system and obtain a list of available hardware decode and encode devices, then specify a specific hardware device for decode or encode. The presentation shows a system with separate GPU, CPU, and Afterburner-based decode/encode. I don't know if this is new or previously existed and was documented now.

The presentation is WWDC 2019 - Session 608, "Metal for Pro Apps":

developer.apple.com/videos/play/wwdc2019/608/

Recent versions of Mac Handbrake have started using hardware acceleration but the developers have complained they don't have access to the underlying features such as quality vs speed tradeoffs.

However DaVinci Resolve on iMacs and the iMac Pro is definitely using Apple's hardware acceleration for both decode and encode of H264. The output quality is very good and performance equal or better than FCPX. Premiere Pro only uses that acceleration for exporting in limited cases. It is still very sluggish on playback, especially seen on 4k H264 as severe lag when doing JKL commands. Supposedly Adobe is working to improve this. The latest 13.1.2 version seems a bit faster on short XAVC-S clips but on longer clips it is still very sluggish to JKL commands.

I formerly had a 2015 15" i7 MacBook Pro and now have a 2016 version. In general the 2016 version was a bit faster on 4k H264 (including export) but it's not a huge difference. If the 2015 version is using Quick Sync and the 2016 T2, I did not notice a huge improvement. However I haven't done encode performance tests on the 2016 MBP recently. If T2 performance was improved on the iMac Pro, maybe it was also improved on the MBP and I haven't tested it.
Last Edit: 12 Jun 2019 13:21 by joema.
The administrator has disabled public write access.