Final Cut Pro 10.6.2 Spotted in Benchmark Tests

Read more...

has anyone gotten the max to get anywhere near full utilization in FCP? i haven't gotten above 25%

Nicely spotted re 10.6.2! While I have no inside information here, I would suspect that the new Storyboard mode isn't going to be in FCP, just like the Trailer mode never has been. Either way, it's hugely welcome because a lot of people need a creative kickstart and all the trailers have been done to death by every school that has access. Starting a project with a template and then transferring it to FCP can be a great way for novices to start out.

ubernaut wrote:

has anyone gotten the max to get anywhere near full utilization in FCP? i haven't gotten above 25%

Yes, transcoding video to Pro Res (full CPU & GPU)  and rendering audio waveforms – especially with audio effects applied. 

hmm i tried that and many other things but don't seem to be able to get the full benefit of this chip only a few items seem to be going full speed using a fresh setup more info here:

discussions.apple.com/thread/253386586

please let me know if you have any idea about what's hanging me up here.

Perhaps could be the still image to video transcode doesn't utilize the media engines. Could also be where you are housing the project & assets. The internal system drive would be assumed, but if you're using external storage, their speed comes into play. try on internal storage.

For me, I'm transcoding h264 to ProRes. Masters are recorded by restroom.io in that format. It's a video podcast show. I'm actually editing for the audio podcast version, but I like the Multicam feature of FCP to edit the isolated audio tracks with. (recorded as separate audio files) That feature doesn't exist in logic. At least not that I could find.

yes home movies folder, if your theory is correct compressor test should confirm the state of things still i think renders should also be faster with 32 core SoC GPU with 16 times as much memory. i will check compressor and give updates thanks for your thoughts.

ubernaut wrote:

discussions.apple.com/thread/253386586

...please let me know if you have any idea about what's hanging me up here.

Your main stated issue is less-than-expected perf. improvement when comparing a late 2013 MacBook Pro (2.6 Ghz 16GB/1TB, 750M) to an M1 Max MBP when exporting ProRes 422 material to H264.

Maybe you are focusing on CPU graphs, which do not always accurately reflect performance. E.g, when encoding if FCP hands off frames to hardware acceleration, that is not counted as CPU usage. It appears that iStat Menus attributes hardware video acceleration to the GPU, even though it is totally separate. Does it do that for all codecs, or some codecs? I don't know. Unfortunately there are no rules about such things and no perf. tool I'm aware of selectively monitors all combinations of hardware video acceleration separate from the CPU or GPU.  There are cases where the hardware is working at full speed but the monitoring tools do not give you visibility on that. The only way to be totally certain of performance is doing timed tests under controlled conditions.

For situations like this, it's important to differentiate between render vs encode performance. Even if the timeline is fully rendered there are various situations in FCP where it may not use those render files to expedite export. This blurs the assessment of what is really causing the slowdown: a general render perf. issue, a specific render perf. issue caused by certain plugins or their order in the Fx stack, a issue with encode perf. during export or an I/O issue when exporting high-bitrate files like 4k ProRes 422.

While you can time render perf. when doing a CTRL+R on selected timeline clips, the time required can vary greatly depending on the Fx and their order in the stack. E.g, if you have an Fx that processes a sliding window of several frames (Neat Video, Flicker Free, etc) that will force recomputation of all Fx above that in the stack for each frame in the window. Thus it is best to put those Fx 1st in the stack, ideally only using one.

The only truly reliable way to segregate render vs export performance is export the timeline as ProRes 422, then re-import that and export it with all Fx baked in using the final codec such as H264. If reading 4k ProRes 422 and exporting to 4k ProRes 422, on M1 Max it is easy to hit an I/O limit if the disk is not an SSD with over about 2 gigabytes/sec bandwidth. If exporting to H264 that is much smaller, involves more compute time (even if hardware accelerated) and you'll rarely hit an I/O bottleneck.

I don't have an older x86 MBP but I have a 10-core Vega 64 iMac Pro and an M1 Max MBP 16. I did several tests with both running Monterey 12.2.1, FCP 10.6.1 and Resolve Studio 17.4.5. Both machines have extremely fast external 4-drive Thunderbolt SSD RAID-0 arrays, and media is on those with export files on the internal SSD.

Summary: in general FCP is very fast and for certain workflows the perf. improvements on M1 Max can be significant. Usually FCP on M1 Max handles most "difficult" codecs much smoother than the iMac Pro. The fastest FCP M1 Max transcoding case is creating 50% ProRes Proxies from 4k ProRes 422. It is incredibly fast, with peak I/O rates of over 1.3 gigabytes/sec. However -- there are several cases where FCP has some performance problems.

One of these has been long known, which is extremely slow 4k 10-bit HEVC export if using the built-in HEVC export preset to a .M4V file. That unfortunately continues on M1 Max. While it is 1.5x faster than an iMac Pro, it is nonetheless 25x (!!!) slower than Resolve Studio 17.4.5 on the same M1 Max machine, exporting with the same HEVC parameters. That's not new to M1 Max, Resolve is about 20x faster than FCP on iMac Pro when exporting to 10-bit HEVC, if FCP is using the built-in preset. However -- if you simply export that to Compressor and create a custom preset with the same resolution, bit depth and bit rate, it is fast. Apple obviously needs to fix that.

There is a known FCP performance bug on M1 Max (maybe all Apple Silicon) where creating 50% H264 proxies from 4k originals is abnormally slow. All other H264 proxy resolutions are fast and creating ProRes Proxies is extremely fast.

If you are using plugins like Neat Video, the latest versions have significantly improved performance on Apple Silicon. If you are using 3rd-party audio plugins, if not updated to Apple Silicon some of those may work in an x86 container process under Rosetta. There could be performance or reliability issues with that.

Other tests below:

** 4k/23.98 ProRes 422 export to 4k/23.98 "fast" H264, I get the following numbers for a 60 sec clip with no Fx **
(all pre-rendering and caching disabled in all cases)

iMac Pro, FCP 10.6.1: 29.3 sec
iMac Pro, Resolve Studio 17.4.5: 29.2 sec

M1 Max, FCP 10.6.1: 18.9 sec
M1 Max, Resolve Studio 17.4.5: 17.4 sec

** 4k/23.98 ProRes 422 export to 4k ProRes 422 (no Fx) **

iMac Pro, FCP 10.6.1: 8.9 sec
Resolve Studio 17.4.5: 2.9 sec

M1 Max, FCP 10.6.1: 3.6 sec
Resolve Studio 17.4.5: 1.9 sec

Curious about that image , how are they doing AV out to a studio display ( no HDMI input), and at the same time spreading the FCP interface across two monitors .

Castiel wrote:

Curious about that image , how are they doing AV out to a studio display ( no HDMI input), and at the same time spreading the FCP interface across two monitors .

support.apple.com/guide/final-cut-pro/co...61bc/10.6/mac/11.5.1

The Pro Display XDR can be set under AV Output. Must be assumed that this new Studio Display can do the same. 

i think we are talking abut two things here render and transcodes. using compressor to test should rule out compositing effects on transcoding but it still doesn't explain why the rendering should go the same speed these are fairly simple projects just stills with ken burns and a title layer. surely the 32 core gpu (which does appear to go at 100% utilization) should be faster than 750M no?

I just did about 30 different tests of various titles, Ken Burns affects on still images, with and without chroma keying, all with and without pre-rendering. Comparing my 10-core iMac Pro to my M1 Max MacBook Pro 16, both running Monterey 12.2.1 and FCP 10.6.1, both using the same media files and same project file via XML. I tested render time, export to H264, and export to ProRes 422 with both rendered and non-rendered timeline.

In general the M1 Max was significantly faster than the iMac Pro. However performance measurement can be tricky due to the unpredictable way FCP uses render cache. This can vary based on what Fx, what order in the stack, machine state, when FCP was re-launched, etc. For details see this and related posts:  www.fcp.co/forum/4-final-cut-pro-x-fcpx/...der-files-for-export

If you can trim down your problem scenario to a few files, inc'l project XML, and upload them to me I'll examine those. Make sure it's using no 3rd-party Fx. If it is, verify you can reproduce the problem without those. Afterward just drop them here:  www.transferbigfiles.com/dropbox/joema

can i just give you a library file containing my test projects with generated files removed? should be pretty small i do not use 3rd party effects.

ubernaut wrote:

can i just give you a library file containing my test projects with generated files removed? should be pretty small i do not use 3rd party effects.

Yes that is OK, I have fiber internet.

sent thanks!

ubernaut wrote:

sent thanks!

There is definitely an issue there. Both render to cache and export to ProRes 422 are much slower on my M1 Max than my iMac Pro. Tomorrow I will test other machines and examine it further.

well at least i'm not crazy thanks again for looking into it.

Another .x update...bummer. Is Apple ever going to do a major revision to version 11? Charge for it and bring some major improvements.

ubernaut wrote:

well at least i'm not crazy thanks again for looking into it.

Here are some tentative findings, although more work is required to nail it down:

- The core problem is not simply that it's slower on M1 Max, although that is one issue.
- Both rendering your timeline to cache or exporting it to ProRes 422 (or anything else) seems abnormally slow on both x86 and M1 Max. E.g, your 30 sec timeline takes about 1 min to render on my iMac Pro and about 2 min to render on the M1 Max. Export to 1080p/60 ProRes 422 likewise takes about 1 min on the iMP and 2 min on the M1 Max, with no difference whether the timeline is rendered or not.
- The problem is worsened by the 60 fps timeline, although it still shouldn't be that slow. If you simply switch the timeline to 23.98 or 25 fps, it will render and export about 2x faster. That is simply a workaround; there's still something wrong.
- Successive simplification of the timeline reveals the root problem involves the title. Is that a custom title you built in Motion? However....
- Even using the built-in FCP title "Lower Third Basic" shows similar behavior.
- The problem includes both slow render, slow export and failure to use pre-rendered cache. That is likely related to the problem I listed previously. See those links for details of my interaction with Apple Pro Apps support. That study involved FCP effects, but I then suspected titles could also be related, however I didn't test those.
- In that previous investigation, there were "well behaved" and "poorly behaved" Fx from a cache standpoint. It appears the same situation may exist with titles. E.g, your title and the built-in "Lower Third Basic" make the timeline render slowly and (worst of all) prevent any re-use of cached frames to expedite export. By contrast the built-in "Basic Title" renders and exports faster but still triggers the "no reuse of cache" behavior. I haven't had time to run tests on many other titles. Lower Third Basic and Basic Title only cause this if they have user-entered title text; the default text doesn't cause it.
- The built-in FCP titles and certain built-in Fx are actually Motion templates. Motion may use some type of interpretive execution engine which in some cases cannot be cached (ie compiled) ahead of time. It's possible those cases somehow prevent re-use of cached render segments in the timeline. I don't know if that's a bug or an unavoidable aspect of the internal design. The impact can be huge, e.g, you could have compute-intensive Neat Video on a bunch of clips, then add a simple title which (unbeknownst to you) prevents re-use of render cache. You then pay the penalty for Neat Video every export, since the Motion-implemented title behavior apparently prevents cache re-use on export. This happens even if no "render dots" are visible on the timeline.
- No matter whether the cache issue is a bug or by design, just rendering or exporting a simple timeline should not be 2x slower on an M1 Max vs an iMac Pro. That is possibly a code optimization issue. I will investigate further.

yes, these are simply modified FCP titles not custom motion ones although they have been migrated from older versions of final cut pro x libraries not sure if that would have any impact. it does seem we are getting close to an answer here. i supposed precomposing or rendering the titles would isolate them as the problem.