Conversation
Add ARM64 solution platform to D3D12Raytracing.slnx and ARM64 Debug/Release project configurations to all standalone raytracing sample projects, mirroring the existing x64 configurations. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
On ARM64 XMVECTOR maps to __n128, which does not accept the
{ x, y, z, w } aggregate initializer that works for __m128 on x64.
Replace those brace initializations with XMVectorSet(), which is
portable across architectures and behavior-identical on x64.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Add ARM64 solution platforms and per-project ARM64 Debug/Release configurations to all standalone desktop samples (Samples/Desktop, TechniqueDemos, Tools), mirroring the existing x64 configurations. Also float the previously hard-pinned toolset and SDK so the samples build with the installed Visual Studio. Set <PlatformToolset> to $(DefaultPlatformToolset) rather than removing it: a bare removal makes x64 fall back to the ancient v100 toolset (ARM64 happens to resolve to v143), so an explicit floating value is required. Retarget <WindowsTargetPlatformVersion> to 10.0 (latest installed). The old v140/v141/v142 and fixed SDK pins referenced toolsets/SDKs not present in current VS installs and blocked building on both x64 and ARM64. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Floating the pinned Windows SDK to the latest installed version (part of the ARM64 build enablement) surfaces ID2D1Factory::GetDesktopDpi as deprecated, which this project's SDLCheck promotes to a hard build error. This is purely an SDK-upgrade compatibility fix and is unrelated to the ARM64 platform itself. Switch to GetDpiForWindow(m_Hwnd) -- the recommended replacement -- which queries per-monitor DPI. m_Hwnd is created before CreateSwapChainResources, so it is valid here; behavior matches the previous single system-DPI value. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
walbourn
reviewed
Jul 9, 2026
walbourn
reviewed
Jul 9, 2026
walbourn
reviewed
Jul 9, 2026
Member
Author
|
Thank you @walbourn for taking a look before I even took it out of draft! |
The prebuilt directx*_desktop NuGet packages are deprecated and their ARM64 static libs fail to link against the current toolset (they reference legacy STL __std_init_once symbols the current arm64 msvcprt.lib only resolves for code built with the current STL). Build these three static libraries from source via vcpkg instead, so they use the same toolset as the samples -- this fixes ARM64 and aligns with Microsoft's deprecation guidance. Header/binary NuGet deps (Agility SDK, DXC, WinPix, WARP) are unaffected. Add a repo-root vcpkg manifest (vcpkg.json + pinned builtin-baseline) and shared MSBuild integration (vcpkg/DirectX.vcpkg.props/.targets) that: - derive the triplet from $(Platform) as <arch>-windows-static-md (static lib, dynamic CRT to match the samples' /MD); - request the directxtex/directxmesh 'dx12' feature (the D3D12 helpers the samples use, e.g. ComputeInputLayout(D3D12_INPUT_LAYOUT_DESC), are off by default in the base ports); - add include\directxtk12 to the include path (vcpkg nests DirectXTK12 headers there whereas the NuGet layout was flat); - derive VcpkgConfiguration from the configuration name so projects like MiniEngine that set RuntimeLibrary directly (without UseDebugLibraries) still link the matching debug/release libraries. Update all consumers to import the shared props/targets, drop the NuGet directx* imports/error-checks, and remove them from packages.config. Uses the vcpkg bundled with Visual Studio by default (no VCPKG_ROOT needed). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
packages.config listed zlib-vc140-static-64, but ModelConverter.vcxproj references zlib-msvc-x64.1.2.11.8900 (imports its targets and links zlibstatic.lib from its lib_release). The referenced package was therefore never restored on a clean machine, failing the build with a missing zlib-msvc-x64.targets. Align packages.config to the package the project actually uses. Verified a clean restore now fetches it and ModelConverter builds and links. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
MiniEngine/Core used x86 SSE intrinsics that do not compile on ARM64: - Utility.cpp SIMDMemCopy/SIMDMemFill: add an ARM64 NEON implementation (vld1q/vst1q) alongside the existing SSE (streaming-store) path, guarded by _M_ARM64. Change the SIMDMemFill signature from __m128 to DirectX::XMVECTOR (identical to __m128 on x64) so it is expressible on both architectures. - Color.h R10G10B10A2/R8G8B8A8: replace _mm_castsi128_ps(_mm_cvttps_epi32(..)) with the portable XMConvertVectorFloatToInt(.., 0) (same truncate-to-int). - CommandContext.cpp FillBuffer: build the fill pattern with XMVectorReplicate instead of _mm_set1_ps. Math/Common.h, Color.cpp and Hash.h already had non-SSE fallbacks, and the _BitScan*/__popcnt intrinsics are available on MSVC ARM64, so no change there. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
MiniEngine's Build.props compiles shaders with -HV 2021 (HLSL 2021), which is a DXC-only option, but set no ShaderModel. VS therefore defaulted to the 4_0_level_9_3 profile and invoked legacy fxc.exe, which on current Windows SDKs rejects both -HV and the compute profile (cs_4_0_level_9_3) -- breaking clean builds on x64 and ARM64 alike (previously masked by cached CompiledShaders). Set ShaderModel 6.0 so the FxCompile task routes to dxc.exe, which supports -HV 2021 and compiles these shaders as SM6. A native arm64 dxc.exe is available. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Add ARM64 Debug/Profile/Release configurations to the MiniEngine Core and Model libraries and the two MiniEngine-based raytracing samples (RaytracingMiniEngineSample, RealTimeDenoisedAmbientOcclusion), mirroring the existing x64 configurations. Also fix XMVECTOR aggregate initialization in RTAO's RaytracingSceneDefines.cpp (invalid for __n128 on ARM64) by using XMVectorSet, matching the earlier raytracing-sample fix. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Add ARM64 Debug/Profile/Release configurations to ModelViewer.vcxproj and an ARM64 platform to ModelViewer.slnx (the existing abstract 'Windows' solution platform continues to map to the x64 project configuration). Core and Model already gained ARM64 configurations with the SSE->NEON port. ModelConverter is intentionally left x64-only: it is an offline content tool that depends on x64-only NuGet packages (assimp, zlib-msvc-x64). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
alexgong14
approved these changes
Jul 9, 2026
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
3 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.
Adds native arm64 support for most of the samples in the repository.
What changed:
Big changes:
A few tools aren't updated due to either pre-existing build complexities, or x64-only dependencies.