search

flutter / flutter

Flutter makes it easy and fast to build beautiful apps for mobile and beyond
https://flutter.dev
BSD 3-Clause "New" or "Revised" License
166.34k stars 27.53k forks source link

[Windows] ☂️ Add support for Arm64 as a target #62597

Open stuartmorgan opened 4 years ago

stuartmorgan commented 4 years ago

https://github.com/flutter/flutter/issues/53120 tracks supporting Windows arm64 as a development environment; this is for being able to build Flutter Windows applications that run on arm64.

This would require:

azchohfi commented 2 years ago

@stuartmorgan it seems like https://github.com/dart-lang/sdk/issues/47824 was merged, so this is mostly technically unblocked? I do have a Surface Pro X, which is Arm64, so I want to help.

stuartmorgan commented 2 years ago

Interesting, I didn't realize that was on the Dart team's radar.

I played around with this quite a while ago and got a PoC of the Dart part compiling, but then ran into the issue that it would require cross-building support, or for the entire compilation of the Flutter engine to be on aarm64 (bullet point #2). Does cross-compilation work at the Dart level (i.e., can Dart AOT compilation be done for arm64, but from an x64 machine)?

If not you could experiment with getting flutter/engine building on arm64, but getting from there to flutter tool support would require CI arm64 machines; I don't know if there's a good option for that available.

(/cc @cbracken )

azchohfi commented 2 years ago

Doesn't seem like cross compilation is a thing yet (https://github.com/dart-lang/sdk/issues/28617). I can try to start things on my Surface Pro X, but that seems challenging. I'll see how far I can get. There are Azure machines that support Arm64, so maybe that is one solution, but not sure how the Flutter team would be able to leverage those.

cbracken commented 2 years ago

Aside from the compilation of the C++ bits, there's also gen_snapshot and the Dart compilation. Today we can generate a gen_snapshot binary that runs on x64 host and targets arm64, but it is not currently possible (without a significant amount of work from the Dart team) to build a gen_snapshot binary that runs on arm64 and targets x64 because there is no simx64 support in the Dart SDK.

On macOS, this isn't a huge problem since we can run x64 code on arm64 macs via Rosetta. It looks like this may be possible on Windows 11 and later. It also looks like there was a preview release for Windows 10 based on this Windows blog post but it's unclear if a final version will be available.

stuartmorgan commented 2 years ago

Today we can generate a gen_snapshot binary that runs on x64 host and targets arm64

Nice! Given the current distribution of machines, that's the most important thing for us to have to get something working end-to-end.

azchohfi commented 2 years ago

@cbracken I believe we should look at these issues as separate issues. This specific issue is tracking building Flutter apps that target Windows 10 and 11 on Arm64. Maybe we can create a cross compiling issue to track making a host Arm64 target x64 binaries. Also, Windows 10 Arm64 will not support x64 emulation. That feature is exclusive to Windows 11 on Arm64, so we can't fully rely on the emulation to have coverage of Arm64. Energy consumption is also always in mind when any kind of emulation is used, so natively supporting Arm64 would provide a better battery life.

The way I see it, we have two options to unblock Arm64 Flutter apps on Windows 10/11: 1) Work to enable cross compilation on x64 hardware. If the compilation is on an Intel x64 machine, that would require cross compiling to Arm64 (which doesn't have a specific issue tracked by Flutter, but does have one from the Dart SDK, https://github.com/dart-lang/sdk/issues/28617, which would be a very first step in getting this to reality). 2) Work to enable all the tooling to work on an Arm64 host machine. If the compilation is happening on an Arm64 machine, then it would require work to enable all the flutter tools to works on Arm64 hosts, but there wouldn't be any cross-compilation effort required here.

Since cross compilation seems like a harder subject to tackle, and since Arm64 hardware on the cloud is starting to be a reality (e.g. Azure already has a public preview of Arm64 VMs), working with option number 2 seems like a better approach. This would unblock developers to build their Flutter apps for Windows 10 Arm64 + Windows 11 Arm64, as well as enabling them to use Arm64 hosts to build their apps locally, with the same great developer tools that work today on Intel x64, with minimal focus on cross compilation.

Does that seem reasonable?

If so, would you be willing to help me drill this down a bit into actionable things to do? I would love to see this become a reality, specially since Microsoft announced Project Volterra.

stuartmorgan commented 2 years ago

Also, Windows 10 Arm64 will not support x64 emulation. That feature is exclusive to Windows 11 on Arm64, so we can't fully rely on the emulation to have coverage of Arm64. Energy consumption is also always in mind when any kind of emulation is used, so natively supporting Arm64 would provide a better battery life.

gen_snapshot is only used during the build, so the emulation here (and associated restrictions) would only apply to developers at app creation time.

The first goal though would be to get the engine cross-compiling (x64->arm64), or compiling natively on arm64, or both. (And if only the later, a CI solution for creating engine artifacts). Without that we can't do anything at the tool level.

cbracken commented 2 years ago

Correct. The minimum set of steps required to be able to develop Flutter apps that target Windows arm64 devices from an x64 host machine is something like (I'm sure I'm missing a pile of items):

The following would be necessary to upgrade Windows ARM64 from a "best-effort" platform to a "google-tested" platform:

citrus77 commented 2 years ago

I'm late to this party and I don't know much about compiling for different architectures, but I have Visual Studio 2022 for ARM64, and Flutter installed on my Surface Pro X, and was able to build for x64. While most devs are probably building on a x64 host, maybe you can provide support faster by targeting an ARM64 host? Especially since Microsoft is set to release that fancy new ARM64 dev box soon.

azchohfi commented 2 years ago

Yes, targeting an ARM64 host is probably an easier path forward. Visual Studio 2022 17.3 Preview 2+ runs as an ARM64 process on WIndows 11, and the toolchain should follow, so this is the least resistance path. The Desktop development with C++ is exactly the type of app that is already supported, so Flutter fits perfectly here. https://devblogs.microsoft.com/visualstudio/arm64-visual-studio/

pbo-linaro commented 2 years ago

Hello, I've been able to compile a native flutter app for arm64 (native build, no cross compilation). This is documented on Linaro's Windows on Arm wiki.

However, I needed to hack through flutter build scripts (see details here). The goal is to upstream all that, starting first with dart-sdk.

Just wanted to say there does not seem to be any blocking issue for native build. Cross compilation will be next target.

citrus77 commented 2 years ago

Great news!

mohitmundhragithub commented 2 years ago

From which version will we have the support ready?

pbo-linaro commented 2 years ago

I started to upstream bits to be able to build flutter engine natively under Windows on Arm (not yet targetting cross compilation) Some more changes will be needed for third party repositories.

Once engine can be built easily, adding app support will be straightforward.

pbo-linaro commented 2 years ago

All patches needed were merged to be able to build flutter engine. Last piece will be to add an option to flutter.bat to target specifically this platform. I'll make a PR for that.

pbo-linaro commented 2 years ago

I plan to add an option --target-platform to flutter.bat build windows command (it already exists for build linux). It will add custom flags to cmake call, allowing to build a native windows on arm app.

Does that sounds right to you?

pbo-linaro commented 2 years ago

I just created the PR to allow building natively arm64 flutter app 👍

pbo-linaro commented 2 years ago

For now, the PR adding arm64 native build is abandoned https://github.com/flutter/flutter/pull/113928. After discussion with @stuartmorgan (see PR), artifacts for this platform is a requirement before going further.

For the people expecting this ASAP, you can follow those build instructions to get a native windows-arm64 app today. The patch it contains is what the PR was trying to upstream.

pbo-linaro commented 2 years ago

@stuartmorgan Windows on Arm can be deployed as a VM (for free) using one of those possibilities:

I'll try to investigate cross-compilation, but meanwhile, could you contact people inside Google to know if it would be possible to get Windows on Arm VM? I sincerely hope a company with such resources is able to deploy a few VM somewhere on an arm64 server. That would allow users to get artifacts available now (flutter engine is building fine natively), while waiting to have cross compilation available later.

Thanks!

pbo-linaro commented 1 year ago

Good news! flutter engine can be easily cross compiled without any modification on an x64 machine:

python3 ./flutter/tools/gn --no-goma --windows-cpu arm64

Results in those files:

analyze_snapshot.exe: PE32+ executable (console) Aarch64, for MS Windows
flutter_tester.exe:   PE32+ executable (console) Aarch64, for MS Windows
font-subset.exe:      PE32+ executable (console) Aarch64, for MS Windows
gen_snapshot.exe:     PE32+ executable (console) Aarch64, for MS Windows
impellerc.exe:        PE32+ executable (console) Aarch64, for MS Windows
dbgcore.dll:          PE32+ executable (DLL) (console) Aarch64, for MS Windows
dbghelp.dll:          PE32+ executable (DLL) (console) Aarch64, for MS Windows
flutter_windows.dll:  PE32+ executable (DLL) (console) Aarch64, for MS Windows
libtessellator.dll:   PE32+ executable (DLL) (console) Aarch64, for MS Windows
msvcp140.dll:         PE32+ executable (DLL) (console) Aarch64, for MS Windows
path_ops.dll:         PE32+ executable (DLL) (console) Aarch64, for MS Windows
vccorlib140.dll:      PE32+ executable (DLL) (console) Aarch64, for MS Windows
vcruntime140.dll:     PE32+ executable (DLL) (console) Aarch64, for MS Windows
VkICD_mock_icd.dll:   PE32+ executable (DLL) (console) Aarch64, for MS Windows
vk_swiftshader.dll:   PE32+ executable (DLL) (console) Aarch64, for MS Windows
vulkan-1.dll:         PE32+ executable (DLL) (console) Aarch64, for MS Windows

@stuartmorgan Who is responsible for adding those artifacts for flutter engine? Can I help on that?

This does not yet solve application cross-compilation, but getting artifacts is the first step towards it. After that, we can enable a native workflow on arm64, as attempted in previous PR.

loic-sharma commented 1 year ago

I'm not very familiar with Flutter's builds, but these look like the relevant resources:

  1. https://github.com/flutter/flutter/blob/master/dev/bots/README.md#editing-a-recipe
  2. https://flutter.googlesource.com/recipes/+/refs/heads/main/recipes/engine/engine.py#1522

You likely won't have permissions to test your changes on Flutter's staging infrastructure using led. I've reached out internally to see what would be the best approach, but in the meantime, we can run led on your patches on your behalf. Feel free to ping us on the Flutter desktop discord channel for that.

FYI, we have holidays this week so our responses may be delayed! I will be out next week too.

pbo-linaro commented 1 year ago

Thanks @loic-sharma. I'll open a different issue (for engine artifacts - https://github.com/flutter/flutter/issues/115983) and try to make a patch on that recipe.

flutter-triage-bot[bot] commented 5 months ago

The triaged-desktop label is irrelevant if there is no team-desktop label or fyi-desktop label.