HandBrake / HandBrake

HandBrake's main development repository

Home Page:https://handbrake.fr

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[macOS] Porting macOS HandBrake to Apple Silicon (Universal Binary)

Nomis101 opened this issue · comments

Description of the feature or enhancement you'd like to see in HandBrake:

macOS Universal Binaries are back. Apple announced the transition to Apple Silicon on todays WWDC. The transition should be completed in two years from now.
https://developer.apple.com/documentation/apple_silicon

This feature request is about porting HandBrake to Apple Silikon to make it run natively on newer Macs. Apple said that it expects its first Mac with custom silicon to launch by the end of 2020.

This WWDC 2020 sessions could be helpful:
https://developer.apple.com/videos/play/wwdc2020/10686/
https://developer.apple.com/videos/play/wwdc2020/10214/

To all concerned, HandBrake does work on 64-bit ARM, HandBrake's graphical interface is macOS native and built with Xcode, and HandBrake's build system is capable of creating universal binaries. Fingers crossed, with a little bit of love we have high hopes this transition will go smoothly. Exciting times.

Yes, the HandBrake own code seems pretty easy to port. I'm more worried about all the third party components that need to update their config.guess or still use #if __x86_64__ instead of #if TARGET_OS_OSX. Especially that ones that haven't seen any update for years.

I pushed a "applesilicon" branch.
CLI and GUI compiles on macOS on Apple Silicon, but cross-compiling from Intel will require a good number of contrib config.guess fixes.

I pushed a "applesilicon" branch.

Nice work! 👍🏻 One question, shouldn't be the T2 HEVC encoder
d8e2f88#diff-1746f7a057818c52c88c68bad91d440eR36
be com.apple.videotoolbox.videoencoder.hevc.ave?

No, com.apple.videotoolbox.videoencoder.ave.hevc is correct.

How do we expect Handbrake to perform on Apple Silicon? Same/Better/Worse?

The A12Z SoC in Apple Developer Kits is the same in recent iPads Pro. Benchmarks like Geekbench 5 suggest it's as fast as a recent model Macbook Pro with Intel i7 CPU. This of course does not account well for SIMD optimizations, so it might be faster still, and it's likely the first Apple Silicon Macs will use a newer yet-unannounced SoC.

So the answer looking on from afar seems to be, definitely not worse when run natively, slower under Rosetta.

I don't know if this is important for us, but Apple's aarch64 calling convention is subtly different from the generic standard in two significant ways:

• Function arguments passed on the stack do not consume 8 bytes apiece, they only consume the space necessary for them (subject to alignment restrictions).
• Caller performs sign/zero extension for arguments < 32 bits, rather than the callee.

https://developer.apple.com/library/archive/documentation/Xcode/Conceptual/iPhoneOSABIReference/Articles/ARM64FunctionCallingConventions.html

(found here: https://bugzilla.mozilla.org/show_bug.cgi?id=1657135)

Calling convention doesn't seem an issue.
arm64e enabled Pointer Authentication, an additional security feature, I have yet to try it.

Cross compile support has been merged: #3176

Universal Binaries for macOS supporting both Apple's Intel Macs and the all-new Apple Silicon Macs are available on https://github.com/HandBrake/HandBrake/releases