Ship native binaries for four RIDs - #4
Merged
Merged
Conversation
win-arm64: the Visual Studio generator was left to pick its own platform, which on the ARM64 runner is not ARM64. Embree then took the x86 code path and immintrin.h rejected the target outright. Pass -A ARM64 (and -A x64 for the other Windows leg, so neither depends on a default), and assert EMBREE_ARM is ON after configuring rather than discovering it halfway through a compile. linux-x64: an x64 build compiles the kernels once per ISA and those translation units are large, so four concurrent g++ processes exhausted the runner's 16 GB. The OOM killer took the runner with them, which is why that job died after 47 minutes with no logs and a Build step still marked in progress. Two jobs there; the NEON legs build a single ISA and keep four.
The check I added asserted EMBREE_ARM=ON in CMakeCache.txt, but Embree sets it with a plain SET(), so it is never a cache entry and the grep could only ever fail. It took down the three NEON legs, two of which had been building fine. Embree prints 'Building for AArch64' / 'Building for Apple silicon' exactly when it takes that path, so match on that instead. The -A ARM64 fix itself was correct: win-arm64 now configures with CMAKE_GENERATOR_PLATFORM=ARM64, reports AArch64 and no longer hits immintrin.h.
Configuring for ARM64 was necessary but not sufficient. Embree gates its ARM code path on __ARM_NEON and __aarch64__, which are GCC/Clang predefines that MSVC does not define on ARM64, so common/sys/intrinsics.h took its x86 branch and included immintrin.h on an ARM target. That is a compile-time failure and no amount of correct configuration avoids it; clang-cl defines both macros. Also adds an only-rid input. Iterating on one platform otherwise re-runs win-x64, which spends an hour compiling four ISAs with MSVC.
Configuring for ARM64 was necessary but not sufficient. Embree gates its ARM code path on __ARM_NEON and __aarch64__, GCC/Clang predefines that MSVC does not define on ARM64, so common/sys/intrinsics.h took its x86 branch and included immintrin.h on an ARM target. That fails at compile time no matter how correct the configuration is; clang-cl defines both macros. The only-rid guard sits on the steps rather than the job: matrix values are not in scope in a job-level if, which GitHub rejects when parsing the workflow. Without it, iterating on one platform re-runs win-x64, an hour of MSVC compiling four ISAs.
Built by Build Embree Libraries at v4.4.1 with EMBREE_TASKING_SYSTEM=INTERNAL, so each library is self-contained and the package carries no TBB. rtcore_config.h is the file that build generated, vendored verbatim so a future diff against a fresh artifact is trivial; it turned out to match the hand-derived one semantically, and regenerating against it produces byte-identical bindings. Verified end to end on win-x64: HelloEmbree passes its struct-size assertions, traces and shadows the scene, and the output folder carries no TBB at all. win-arm64 is dropped. Embree 4.4.1 does not build for Windows on ARM with either toolset: MSVC does not define the __ARM_NEON/__aarch64__ macros Embree gates its ARM code path on, so it includes immintrin.h on an ARM target; clang-cl defines them and clears that, only for Embree's CMake to feed -msse2 to an arm64-pc-windows-msvc target. Both are upstream gaps in a configuration Embree does not test, and working around the second means carrying a patch to its build system for a kernel where a wrong SIMD path yields wrong intersections rather than a crash.
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
1 participant
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.
Completes phase 2: the package now carries the native Embree libraries, so it goes from
"compiles" to "works".
Binaries
Built by
Build Embree Librariesat v4.4.1 withEMBREE_TASKING_SYSTEM=INTERNAL, so eachone is self-contained and nothing drags TBB into the package:
win-x64embree4.dlllinux-x64libembree4.solinux-arm64libembree4.soosx-arm64libembree4.dylibrtcore_config.his the file that build generated, vendored verbatim so diffing a futureartifact against it is trivial. It came out identical on all four platforms and matched the
hand-derived one semantically — regenerating against it produces byte-identical bindings.
Verified end to end on win-x64:
HelloEmbreepasses its struct-size assertions, traces thescene with shadows, and its output folder contains no TBB.
Workflow fixes
Three legs needed work before any of this existed:
linux-x64was being OOM-killed. An x64 build compiles the kernels once per ISA andthose translation units are large, so four concurrent
g++processes exhausted the runner's16 GB. It surfaced as a job that died after 47 minutes with no logs and a
Buildstep stillmarked in progress, rather than as a compiler error. Now
--parallel 2.-A x64/-A ARM64explicitly.only-ridinput rebuilds a single leg. Iterating on one platform otherwisere-runs
win-x64, which spends an hour compiling four ISAs with MSVC.There is also a
Check ARM detectionstep. Note it greps Embree's configure output ratherthan
CMakeCache.txt:EMBREE_ARMis set with a plainSET()and never reaches the cache, soan assertion against the cache file fails on a perfectly good build — which is exactly what it
did, taking down three legs that had been fine.
win-arm64 is dropped
Embree 4.4.1 does not build for Windows on ARM with either toolset on the runner, for two
different reasons, both upstream. Details in #3, and the reasoning is recorded in the matrix
comment so the next person does not repeat it.