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.

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.