Question regarding the use of my CPU/GPU when exporting from FCPX (seems really low)

[Noah Kadner]

Straight exports are typically to GPU. Certain plugins use more CPU as well as h.264 exporting to name a few. In my experience watching Activity Monitor during export isn’t particularly useful.

Noah

FCPWORKS – FCPX Workflow
FCP Exchange – FCPX Workshops
XinTwo – FCPX Training

[Jordan Sarkisian]

Yeah I ran some more tests afterwards using this iStat app for OSX. The CPU was still pretty damn low but I saw the GPU “Processor” and “Memory” was almost maxed out lol. I guess it just uses GPU and saves CPU for whatever else you’re doing. I also did the same test with my old MacBook using Iris Pro and it didn’t even have the “Processor” option under the GPU anymore but it was about 50-60 degrees hotter, fans were twice as fast and louder sounding, and it took about 80% longer to export. I guess everything is working fine, just seemed odd to me it uses so very little of the CPU for exporting. Just that much more efficient and cuts down on heat I guess?

[Joe Marler]

[Jordan Sarkisian] “…exporting a few different projects and different ways from FCPX to test my new laptop (maxed out MBPTB except SSD size) and the exports are giving me very different results. Some projects will use all the CPU cores….and other times when exporting it’ll use barely any CPU at all…For $2700 I feel like I should be using at least all 8 cores even if it’s low on each right? “

Exporting consists of two tasks (1) The timeline must be fully rendered, and (2) The rendered timeline must be encoded to the designated export codec.

If you are encoding to H264 this cannot be accelerated by traditional GPU methods since the core algorithm is inherently sequential. Each frame in a GOP (Group Of Pictures) must be encoded before the next. Each GOP can be processed in parallel but there aren’t enough GOPs in a typical file to effectively harness the thousands of lightweight threads a GPU offers. Thus a multi-core CPU is typically used for this, one core per GOP, then walking down the file.

The only exception to this is speeding up the sequential encoding thread by using dedicated hardware. That is what Quick Sync does — it’s essentially dedicated hardware logic which processes the innermost encoding algorithm faster. Although logically separate from the GPU, Quick Sync requires resources from the on-chip GPU so it cannot exist independently as currently designed. If Quick Sync is used during export, the CPU core utilization may be lower since much of the work is being done by Quick Sync. That is not bad — it’s good. You can typically export 4x or 5x faster to H264 using Quick Sync, yet the CPU will be lower. Your goal is do the job faster not have the highest CPU numbers.

Why your different results? If the timeline contains unrendered effects, these must be rendered before being encoded. Depending on the effect that could require CPU, GPU or both. It will be highly variable depending on your timeline.

Another variation is whether you have background rendering enabled. If enabled (which is the default), FCPX will have done varying amounts of background rendering. If the timeline has been fully rendered and you export to H264 using Quick Sync, you might see lower CPU utilization. If the timeline has not been rendered and requires CPU to achieve this, you might see higher CPU levels during export.

Your CPU doesn’t have 8 physical cores. It is hyperthreaded and has 4 physical cores and 8 logical cores. While this can help many CPU-intensive workloads, it’s also possible to encounter “cache thrashing” in the CPU instruction/data cache. It appears the macOS thread scheduler tries to avoid this and sometimes will only schedule 4 cores not 8, or some combination in between. I don’t know what criteria it uses.

If you want to see high CPU numbers, you can export from Premiere — your CPUs will be maxed out and it will export at 1/4 the speed.

[Jordan Sarkisian]

Great response! I learned so much, much appreciated:)