Add Windows ARM64 and ARM64EC build support#11599
Open
RyanEwen wants to merge 1 commit into
Open
Conversation
Native ARM64 - Detect ARM64 as the target platform in the dependency and application CMake, giving the generator platform (-A) precedence over the host processor so an ARM64 host can also build x64 or ARM64EC targets. - Match ARM64 case-insensitively, since build_win.bat passes "-A arm64" while CI passes "-A ARM64" and CMake keeps CMAKE_GENERATOR_PLATFORM verbatim. - Alias libmpfr-4.lib next to the shipped libmpfr-6.lib so CGAL's FindMPFR, whose name list predates the MPFR 4.x "-6" ABI naming, resolves it. - Pin OpenCV_ARCH and OpenCV_RUNTIME (ARM64, vc17) so find_package matches the installed layout; OpenCV 4.6's dispatcher misclassifies MSVC 194x (VS 17.10+). - Configure OpenSSL as VC-WIN64-ARM, add an ARM64 branch to FindGLEW, and build OpenCV and libjpeg-turbo with IPP and SIMD off, since no ARM64 build exists. - Use the generic C encoder path in minih264e (its NEON path is gated on the GCC/Clang macros that MSVC never defines) and the portable multiply in Int128 (ARM64 MSVC has no _mul128). Add ARM64 branches to StackWalker and BaseException (ARM64 CONTEXT has no EFlags). - Use BtbN's winarm64 FFmpeg build, since the bundled prebuilt is x64 only. - Add a windows-11-arm CI job that builds and publishes an arm64 portable zip. ARM64EC ARM64EC is native ARM64 code with the x64-compatible ABI, so an ARM64EC process can link the x64 dependency set and load x64-only DLLs, including the closed-source Bambu network plugin, in process. - Build the dependency bundle with -A ARM64EC. This injects the flags EC needs (force-include intrin.h so the x86 SIMD headers resolve through the emulation layer, and silence the resulting C4996/C4005), selects the winfib Boost.Context implementation, excludes Boost.JSON and cobalt (they require __shiftright128, which has no EC lowering), patches oneTBB to drop the hard-coded /GL and to stub the TSX intrinsics, and builds OpenSSL under the x64 cross environment. - Link softintrin.lib and add a standard C fallback for _mm_cvtsd_si64 in Clipper2, which have no native EC lowering. - Add a windows-11-arm arm64ec CI job and put the architecture in the dependency cache key so the two variants do not collide on the same runner. Build system - Use /Z7 debug info under the Ninja generator (its parallel compiles cannot share the per-target /Zi PDB, which otherwise fails with C1041), limited to the debug-carrying configurations so a Release static library stays under the 4 GB archive limit. All ARM64 and ARM64EC logic is gated so the existing x64, x86, macOS and Linux build paths are unchanged.
This was referenced Jul 19, 2026
ArthurBambulab
removed their request for review
July 19, 2026 02:34
Haidiye00
removed their request for review
July 20, 2026 01:24
Contributor
|
good job |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this does
Adds native Windows on ARM support to BambuStudio in two variants:
ARM64, including OCCT/OpenCASCADE, so STEP import, SVG to 3D and text emboss
all work. The one limitation is the network plugin (see below).
process runs the application at native speed and can still load x64-only DLLs
in process, which is what allows the closed-source Bambu network plugin
(cloud login, device management, camera) to work. Bambu currently ships that
plugin as x64 only, so this is the variant most users on ARM would want.
Both are folded into the existing Windows build matrix on the
windows-11-armrunner. All ARM-specific logic is gated, so the x64, x86, macOS and Linux
paths are unchanged.
Why
Windows on ARM machines (Snapdragon X and similar) currently run BambuStudio
under x64 emulation. A native build removes the emulation overhead from
slicing, and the ARM64EC variant keeps full networking/device support while
doing so.
Notes for reviewers
windows-11-armGitHub runner ships Visual Studio 2022, not 2026, so theARM jobs use the
Visual Studio 17 2022generator and resolve the WindowsSDK at runtime rather than pinning it.
were already present in the tree. MPFR 4.x ships as
libmpfr-6.lib, so analiased
libmpfr-4.libis installed for CGAL'sFindMPFR.bundled prebuilt package is x64 only. The tag and hash are pinned.
/GLthat blocks EC links, and stub the Intel TSX intrinsics, which are unreachable
under emulation but must resolve at link). The patch is a no-op on non-MSVC
toolchains.
environment, since ARM64EC links the x64 static libraries.
Testing
windows-11-arm; the x64, macOS and Linux jobs remain green.slices, imports STEP, and loads the x64 network plugin in process (verified
by module list and by signing in to a Bambu account and driving a printer).
Not included
Signed installer and release-pipeline wiring for the ARM artifacts are left as
a maintainer follow-up. This is a build-and-CI change.