Support for Apple Silicon

[richiksc]

With the release of the new ARM-based M1 MacBooks, along with all the Linux systems that are ARM-based (Raspberry Pi, Nvidia Jetson, etc), what is the extent of the native support for ARM on WPILib? Are native libraries like ntcore ported to arm64? Is there any intent to support apple-arm64 or linux-arm64 as a development platform, including parts of the toolchain like Shuffleboard, and if so, is there any roadmap? I'm willing to contribute and help out if this is something that has support/demand.

[prateekma]

We currently have no plans to natively support Apple Silicon for the 2021 season. None of the developers have the hardware to add the capability across our suite (native-utils, tools, allwpilib, thirdparty-opencv, etc.), and we cannot build Apple Silicon natively on CI because Actions doesn't have Apple Silicon runners yet.

You should be able to run all of our current tools under the Rosetta 2 translation layer for now. Note that we do have native binaries for Linux Raspbian as well as Linux Arm64 (Aarch64).

[richiksc]

@prateekma I understand the decision to not support Apple Silicon for 2021 - given developers' access to hardware, and that the timeframe is just too short between now (the release of ASi) and the beginning of the 2021 season. Rosetta 2 should be a decent enough solution.

One thing regarding GitHub Actions - they are upgrading their macOS runners to macOS 11.0 with Xcode 12, and Xcode 12 does have support for cross-compilation for Apple Silicon, even when running on an x86_64 system. I may be wrong, but this means that Apple Silicon runners aren't necessary to compile for ASi on GitHub Actions.

[prateekma]

Yep, that is correct. It is possible to build for Apple Silicon on Intel Macs (just one compiler flag: -target arm64-apple-macos11). However, I don't think it is really trivial to add to all of our Gradle builds and we have no way of testing the binary output.

I can probably investigate this when I have time but don't expect any hard official support for 2021. We will try our best to officially support it for 2022.

[richiksc]

@prateekma Thank you for the quick and clear response!

[ssysm]

wpilib currently build with no problem on apple silicon via rosetta 2. Sim works as well. As long as apple not ditching rosetta 2, wpilib is pretty safe running on a compatibility layer.

[richiksc]

@ssysm I'll be receiving my M1 system soon, so I'll report any specific issues I run into this season under Rosetta 2. Thanks for letting me know it works smoothly on Rosetta! Peace of mind.

[ssysm]

I got my hand on a native build of JDK 11, unfortunately WPILib does not build with the native JDK :(, looks like the building process have to stick with Rosetta 2.

[prateekma]

I got my hand on a native build of JDK 11, unfortunately WPILib does not build with the native JDK :(, looks like the building process have to stick with Rosetta 2.

There are a lot of things that we need to do on our side to enable native Apple Silicon builds, especially in native-utils. That will probably happen after the 2022 season.

[richiksc]

I got my hand on a native build of JDK 11, unfortunately WPILib does not build with the native JDK :(, looks like the building process have to stick with Rosetta 2.

@ssysm Which JDK was that - the Azul OpenJDK? And also, by building do you mean building the wpilib project or building a robot project using WPILib on the native JDK? I was looking forward to using Azul OpenJDK this build season. I can do some more testing if necessary once my hardware is delivered.

[ssysm]

I got my hand on a native build of JDK 11, unfortunately WPILib does not build with the native JDK :(, looks like the building process have to stick with Rosetta 2.

@ssysm Which JDK was that - the Azul OpenJDK? And also, by building do you mean building the wpilib project or building a robot project using WPILib on the native JDK? I was looking forward to using Azul OpenJDK this build season. I can do some more testing if necessary once my hardware is delivered.

@richiksc Yep, the Azul OpenJDK. I tried both building the wpilib project and building the robot project, both failed.

[richiksc]

When I use Rosetta and the x86_64 build of OpenJDK 15, my project builds, but unit tests that use WPILib libraries and requires halJni fail. This one used Timer.

% arch -x86_64 ./gradlew build

% ./gradlew build

Both of these have the same issue. Here's the failure output for the build: https://gist.github.com/richiksc/2fcb9b23810566e0e5f70a6dc84fbbb9

[prateekma]

@richiksc What version of GradleRIO was the project using? We fixed an issue with loading dynamic libraries in Beta 2.

[richiksc]

@richiksc What version of GradleRIO was the project using? We fixed an issue with loading dynamic libraries in Beta 2.

@prateekma The project uses GradeRIO v2020.3.2

[prateekma]

@richiksc Ok, that is a known issue and occurs even on Intel platforms. We fixed that problem in v2021.1.1-beta-2 so when we publicly release for the 2021 season, it should also be resolved on your end.

[bobwolff68]

Hi there - Team 1967 mentor here - I think the compilers are likely just fine to run via Rosetta 2 like you suggest. However, I'm concerned about what happens if I update my Visual Studio Code to M1 native -- what happens to the WPIlib plugin if it is only offered in Intel_64. I just don't want to paint myself into a corner but was hoping to update my VSCode to M1 as soon as I can, safely.

[ThadHouse]

We don't run any native code in the plugin, so that should be platform agnostic. However, I'm not sure about the Java plugin, and I'm almost positive the c++ plugin wouldn't work. But there is nothing we can do if those are broken except wait for them.

[richiksc]

We don't run any native code in the plugin, so that should be platform agnostic. However, I'm not sure about the Java plugin, and I'm almost positive the c++ plugin wouldn't work. But there is nothing we can do if those are broken except wait for them.

I believe the plugins are just Node/TypeScript code which run on the VSCode runtime itself (which work) and then hook into the locally installed Java and C++ runtimes (which also work). The plugins are also Microsoft-developed, so they're likely to be up-to-date. I haven't tested it, since I use IntelliJ, but they should work. I've used the Python plugin with the M1-native VSCode without issues.

[ThadHouse]

The C++ plugin interacts with its language server, which is written in native code, and is started by the plugin. So I'm not sure if that has a native version, but in theory it should work under Rosetta 2. The Java plugin runs its language server in Java, and I don't think that has native dependencies, but it might.

[richiksc]

@ThadHouse Oh, thanks. That makes sense. Looks like the C++ extension works on M1 and runs its language server under Rosetta: https://github.com/microsoft/vscode-cpptools/issues/6713

but ARM-native support is in progress: https://github.com/microsoft/vscode-cpptools/issues/6595

[bobwolff68]

Great discussion - thanks for this info. I'll give a shot at using the M1 version of VSCode with WPILib in the next few weeks as things taper off for the season. Thanks!

[bdaroz]

Any update on this?

Could not determine the dependencies of task ':extractReleaseNative'.
> Could not resolve all files for configuration ':nativeRelease'.
   > Failed to transform hal-cpp-2022.1.1-osxx86.zip (edu.wpi.first.hal:hal-cpp:2022.1.1) to match attributes {artifactType=gr-directory, org.gradle.status=release}.
      > Could not find hal-cpp-2022.1.1-osxx86.zip (edu.wpi.first.hal:hal-cpp:2022.1.1).

I saw the item in known issues (just now) but installing an x86 version of the JDK isn't an option as it breaks other things and student's can't run VSCode on their school computers.

[calcmogul]

Nope. The only recourse is running an x86 JDK through Rosetta. M1 compiler support isn't even generally available yet (we're a few versions behind at GCC 8 and the LLVM that comes with macOS 10.15).

[ThadHouse]

That is correct. Without being able to install an x86-64 JDK, you will not be able to build robot projects. I can make a patch so you could build robot code on M1, which would unblock robot code, but simulation will not work for a native M1 JDK in 2022.

[mjhealy]

Any updates on plans for supporting Apple Silicon?

Among other things, it looks like this is a blocker for being able to use the unit testing support in WPILib, since building C++ test code fails due to linker problems (since the libraries are built for macOS-x86_64, but the test apps are being build for macOS-arm64).

[calcmogul]

macOS ARM support was merged into native-utils in June (https://github.com/wpilibsuite/native-utils/pull/104). We'll have all the relevant compilers and WPILib built for macOS ARM for 2023.

[sciencewhiz]

The last changes have been merged, and with the exception of smartdashboard, everything will be supported on mac arm (SysID support will come later). People interested in testing should sign up to be beta testers. https://www.firstinspires.org/robotics/frc/blog/2022-control-system-reporting-2023-updates-and-beta-testing

[mjhealy]

That's great news, thanks for the update!