Final Cut Pro 10.6.2 Spotted in Benchmark Tests

ubernaut wrote:

i supposed precomposing or rendering the titles would isolate them as the problem.

That is correct. If you could do that, it would eliminate the current problem.

Obviously that should not be required; it is a workaround. I think the underlying issue involves the Motion runtime engine. Assuming that 95% of built-in FCP Fx are Motion-based, there are two separate cases:

- Fx can be rendered to ProRes 422 cache and re-used for export, so the Fx does not need recomputing.

- Fx is rendered to ProRes 422 cache but is blocked from re-use for export (and also all layers and Fx within the same timeline range), so all in that range must be recomputed.

In addition to the cache problem the computation itself of certain Motion-driven Fx is apparently less efficient on Apple Silicon than x86. So those two problems feed on each other.

all of that makes sense, also seems to explain why HEVC exports were in line with my expectations. hopefully, it means at some point there be an update that just makes the renders at least faster. sounds like the export cache issues you've been trying to get recognition of will be a harder battle.

were you ever able to figure out exactly which effect in the title stack was causing this?

ubernaut wrote:

were you ever able to figure out exactly which effect in the title stack was causing this?

Unfortunately I'll be working on a different project for at least a week, and cannot continue examination of the above problem until after that. However my testing to date implies many (if not most) of the built-in titles prevent re-use of existing render cache to accelerate export. 

To review, there are three separate issues:

1 - Various built-in FCP effects and many (if not most) built-in titles will prevent use of FCP render cache to accelerate export. I suspect this involves the Motion runtime engine which implements these effects and titles. 
In this case when the timeline is rendered to cache, the timeline runs smoother, so the cache is properly used for that. However it is not used for export, and all Fx & titles must be recomputed from scratch. This is most apparent if exporting to ProRes 422 on a fast machine with SSD drives. If you are exporting to H264 it may be less obvious since encoding itself can be a bottleneck.

2 - Some combinations of titles or Fx may prevent use of render cache, even to accelerate timeline operations. After background render or manual render to cache via CTRL+R, No render dots appear on the timeline, yet timeline operations are still slow. I have less info about the specifics and it will take more testing to better define this.

3 - Some built-in FCP Fx and titles are significantly slower to render on an M1 Max machine than x86 machines which should be slower than M1 Max. Comparing a 10-core Vega 64 iMac Pro to an M1 Max MacBook Pro 16, this varies by effect. Some effects such as Neat Video render about 2x faster on the M1 Max. This implies some inefficiency or bottleneck in the some Motion-implemented titles and effects which are unique to Apple Silicon.

In general Apple Silicon Macs are fast and overall I'd rather use my M1 Max than the 10-core iMac Pro. However even before Apple Silicon, there have been some long-standing issues with FCP render cache, and now there are apparently some new issues with runtime efficiency of the Motion engine for some tasks, unique to Apple Silicon.

It will be interesting to re-test these cases when FCP 10.6.2 is released.

yeah, no rush and thanks for your insight on this hoping it will be as easy as removing some element of the title effects to speed things up while we wait for the real fix to #3. unfortunately, it's a bit tough for me to test on my end since my old mac is basically decommissioned at this point.

Hi there,After just getting an M1max MacBook, and being very disappointed with its FCPx performance, I spent a couple of hours online with Apple Support yesterday who after trying all the remedies they could think of including reinstalling FCPx, did eventually agree that performance is not what it should be. Looking at the Activity monitor shows that neither the CPU's or GPU's were coming close to being fully utilised, especially when exporting h264 files, and handling text in the time line, so I have been conducting more tests and doing some head to head comparisons with my 2017 MacBook Pro to try and get a better idea of what is going on.Working on the exactly the same FCPx library/project on both machines the M1max is approximately 3x faster when it comes to rendering (into ProRes) and exporting the timeline as a ProRes file. Looking at the activity monitor whilst this is happening it looks like the M1 is utilising the Graphics cores to do this. The CPU usage never really exceeds 15%, whereas the GPU usage goes up to around 50%.Attempting to export an h.264 file, the 2017 mbp is 5x faster than the M1max, this is the same whether the time line has been rendered first or not. Looking at the activity monitor on the 2017 shows that everything is working hard (the CPU at around 85% and GPU around 50%) where as on the M1max the CPU never goes above 15% and the GPU seems to be hardly working at all.This kind of leads me to the conclusion that FCPx on the M1 series is only optimised in any way for ProRes workflows, which is great if all you are doing is high end work, but hopeless if you are wanting to export h.264 files. I have an 8 part documentary series on Amazon which all had to be exported in ProRes, but for the average video producer who is wanting to export things for Youtube and Vimeo, as things stand now an M1 max is a waste of money. Even using entire ProRes workflows where the original footage is in ProRes and the final export is also, the CPU and GPU never come close to being fully utilised, and the fan never comes on that I can hear, even when the unit is in high power mode, so having all these CPU and GPU cores is a waste of time because they never get used. I’ve had a look around the internet and found quite a few other people who are of the same opinion For the amount that they cost, it would seem that they are aimed a higher end creative professionals. It is pretty scandalous that the a software package like Apple’s own Final Cut can’t utilise the resources in these fantastically expensive machines, and really I am finding it difficult to justify the expense unless this computer starts to perform at least half as well as the hype had led me to believe it would.As I am writing I am attempting to export an hour long h.264 video on both machines. Both got off to a good fast start, but after 20 minutes both are now crawling along, though the M1max is going faster. The fans on the 2017 are working hard and the whole machine is feeling very warm. The M1 is warming up but no fan noise is audible.So it took the M1max 1 hour to export a 1 hour video, the 2017 is still working on it. Out of interest I got Davinci Resolve to export same thing in the closest format I could, and that took just 12 minutes. Looking at the activity monitor the CPU usage for Resolve was lower (about 90% as opposed to about 120% for FCP, but the GPU usage was higher (around 35% as opposed to 2% for FCP), it had many more active threads (over 2000 as opposed to around 50 for FCP) so it appears that Davinci Resolve is much more optimised for the M1Max, though it still doesn’t come close to using all the chips available.

You must have 10.6.4.

Please post an EtreCheck report etrecheck.com giving the application Full Disk Access in Privacy System Preferences. Copy the report and use the Add Text button to paste the result into reply box.

Antwarrior wrote:

...Looking at the Activity monitor shows that neither the CPU's or GPU's were coming close to being fully utilised, especially when exporting h264 files...

In general, a pure export (minus effects) to H264, HEVC or ProRes on Apple Silicon will not show high CPU or GPU levels. This is because the hardware encoder is handling the task and that is not instrumented to show up in Activity Monitor, iStat Menus or anything else. 

Antwarrior wrote:

....Attempting to export an h.264 file, the 2017 mbp is 5x faster than the M1max, this is the same whether the time line has been rendered first or not...

I have a 2017 iMac 27, 2019 i9 MacBook Pro 16, and M1 Max MacBook Pro 16. I have tested them many times on many codecs. In general the M1 Max is faster at everything, however there might be some rare edge cases involving specific effects where it's not. In a controlled test I have never seen an Intel Mac faster at a pure H264 export (minus effects) than an M1 Max.

A good troubleshooting approach is duplicate the timeline, then open it and remove all effects via CMD+A to select all clips and Edit>Remove Effects to remove them. Then try exporting the timeline using this preset:

File>Share>Export File>Settings,
Format: Computer
Video Codec: H.264 Faster Encode
Resolution: 1920x1080 or 3840x2160

It is not necessary to use H.264 Better Quality.

If that export is fast then the problem may be some effect you are using. In general all built-in FCP effects are quite fast. There are some 3rd-party effects such as Neat Video that are quite slow, but they do a valuable job. 

In this case delete 1/2 of the timeline, then 1/4, etc, exporting each time to narrow down what effect is causing the problem.

Normally compute-intensive effects would be slow on both Intel and Apple Silicon, so Intel being 5x faster is unusual. There might be cases where an effect developer has not produced an Apple Silicon version and recommends that FCP run in Rosetta emulation. IMO that should never be done. Sometimes with AU plugins they do this on the separate host process, which can also cause problems. Apple Silicon has been out for two years and they've had plenty of time to port their plugins. Using Rosetta is not a long-term solution.

Antwarrior wrote:

...Looking at the activity monitor on the 2017 shows that everything is working hard (the CPU at around 85% and GPU around 50%) where as on the M1max the CPU never goes above 15% and the GPU seems to be hardly working at all.This kind of leads me to the conclusion that FCPx on the M1 series is only optimised in any way for ProRes workflows...

FCP is highly optimized for Apple Silicon. CPU and GPU are not good guidelines because the hardware accelerators are separate hardware and not reflected by those graphs. Why Apple does not expose performance counters for those, I don't know. On Windows, separate perf. counters exist for hardware video accelerators.

The real-world execution time for a known workload is a good indicator. If the CPU and GPU graphs on M1 are very low AND the execution time is slow, then something is wrong. That does not mean FCP is not optimized for Apple Silicon or only optimized for ProRes. Rather there is likely some thread bottleneck on a resource, possibly caused by a 3rd-party plugin. The way to isolate that is stated above: using that H264 export preset, remove all Fx from a copy of the timeline and narrow down what effect is causing it.

Antwarrior wrote:

....using entire ProRes workflows where the original footage is in ProRes and the final export is also, the CPU and GPU never come close to being fully utilised, and the fan never comes on that I can hear, even when the unit is in high power mode, so having all these CPU and GPU cores is a waste of time because they never get used...

That is because the ProRes encode/decode accelerators on Apple Silicon are so fast that there's nothing for the CPU & GPU to do in that phase. The M1 Max is so fast at ProRes export it can hit several gigabytes per sec, which will bottleneck on any external SSD except the very fastest ones. It's not as fast at H264 export but it's still much faster than non-accelerated encoding. Unlike most Windows machines, Apple Silicon does hardware-accelerated 10-bit 4:2:2 export.

Antwarrior wrote:

....I am finding it difficult to justify the expense unless this computer starts to perform at least half as well as the hype had led me to believe it would...

I'm sure there is a straightforward answer to your situation. If you try the above suggestions and supply us with information, we can help you. 

Antwarrior wrote:

...Out of interest I got Davinci Resolve to export same thing in the closest format I could, and that took just 12 minutes. Looking at the activity monitor the CPU usage for Resolve was lower (about 90% as opposed to about 120% for FCP, but the GPU usage was higher (around 35% as opposed to 2% for FCP)....

I have Resolve Studio 18 and use it daily on both Intel and M1 Max. Resolve is definitely fast on decode/encode but I've never seen a case where it's vastly faster than FCP. In general FCP exhibits a more responsive, fluid editing experience, as shown by viewer update rate and lag time to JKL input when doing forward/reverse at 8x speed.

Because of differences in Fx, I suggest you try exporting the timeline without effects on FCP (using the above-listed H264 preset) then compare the same export minus effects in Resolve. When Fx are involved it's difficult to benchmark Resolve because the caching system is so complex. The user manual for Resolve is over 4,000 pages.