feat: Adds native dependencies for win-arm64 #2644

azeno · 2025-02-16T21:03:48Z

PR Details

Allows to develop and also run games on win-arm64.

Needs MSVC v143 - VS2022 C++ ARM64 build tools (Latest)

The used versions of those dependencies are often rather dated and didn't build out of the box on win-arm64 / Visual Studio 2022, minimal patches had to be applied. Need to push/document those separately.
As far as I understood PVRTexLib is delivered as binary only and there's no win-arm64 - therefor added a check to not load it at all. In the end it's only needed by the asset compiler, which in turn is platform neutral. However when invoking it on a arm64 machine, the dotnet path/to/asset/compiler will launch it in arm64. If there would be some option to launch it in x64 we wouldn't have any issues with asset compiling. Still the editor might have issues, since its running in process?
Removed the FreeImageNET load - it's not used anywhere in code
Fixes some PInvoke signatures in DxtWrapper

The game studio also runs on arm64, but one must set the runtime identifiers in Stride.GameStudio/Editor/Assets.Presentation accordingly. Would be nice to add an arm64 version to the installer, but different topic I'd say.

FFmepg

checkout.bat says to use n3.3.3 tag however I didn't manage to get it to build. Was therefor using release/3.4 as a base.
Basically had to cherry-pick two commits from main branch in regards to arm64.
A quick test with importing a video asset and playing it later in the game worked.
https://github.com/azeno/FFmpeg/tree/win-arm64

FreeImage

Added a checkout.bat file which will also apply the needed fixes

Recast

Guessed the commit by comparing the checked in header files to those in the original repo. Added the used commit-id to checkout.bat file.

Needed PRs in other repos

Related Issue

#2397

Types of changes

Docs change / refactoring / dependency upgrade
Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to change)

Checklist

My change requires a change to the documentation.
I have added tests to cover my changes.
All new and existing tests passed.
I have built and run the editor to try this change out.

deps/FFmpeg/dotnet/build.sh

sources/core/Stride.Core/Native/NativeLibraryHelper.cs

Kryptos-FR · 2025-02-16T21:21:45Z

sources/engine/Stride.Audio/Stride.Native.Libs.targets

-    <StrideNativePathLibsWindows>libCompilerRt.lib libCelt.lib</StrideNativePathLibsWindows>
-    <StrideNativePathLibsUWP>libCompilerRt.lib libCelt.lib Xaudio2.lib</StrideNativePathLibsUWP>
+    <StrideNativePathLibsWindows>libCelt.lib</StrideNativePathLibsWindows>
+    <StrideNativePathLibsUWP>libCelt.lib Xaudio2.lib</StrideNativePathLibsUWP>


Are you sure this lib is not necessary?

The linker was happy. It would've complained I assume.

Jklawreszuk · 2025-02-16T22:28:40Z

sources/tools/Stride.TextureConverter/Backend/Wrappers/DxtNetWrapper.cs

        private extern static void dxtComputePitch(DXGI_FORMAT fmt, int width, int height, out int rowPitch, out int slicePitch, CP_FLAGS flags);

-        [DllImport("DxtWrapper", CallingConvention = CallingConvention.Cdecl, CharSet = CharSet.Auto), SuppressUnmanagedCodeSecurity]
+        [DllImport("DxtWrapper", CallingConvention = CallingConvention.Cdecl, CharSet = CharSet.Ansi), SuppressUnmanagedCodeSecurity]


Ansi ? Why?

If we look in the C header, the method is defined with char (1 byte). With Auto we don't know what it will take, clearly on arm64 it took the wrong one. I debugged that part, the data I got on unmanaged was garbage with Auto. With Ansi all good.

Seems legit. I quickly tested on Linux DDS and TGA files, no regression here 👍

azeno · 2025-02-17T17:50:23Z

@Kryptos-FR @Jklawreszuk I just force pushed - added more info in the PR summary. For those deps where Stride maintains a fork I created PRs, and for those where it doesn't I added patch files or forked myself if the original repo was hosted on github.

- The used versions of those dependencies are often rather dated and didn't build out of the box on win-arm64 / Visual Studio 2022, minimal patches had to be applied - As far as I understood PVRTexLib is delivered as binary only and there's no win-arm64 - therefor added a check to not load it at all. In the end it's only needed by the asset compiler, which in turn is platform neutral. However when invoking it on a arm64 machine, the `dotnet path/to/asset/compiler` will launch it in arm64. If there would be some option to launch it in x64 we wouldn't have any issues with asset compiling. Still the editor might have issues, since its running in process? - Removed the FreeImageNET load - it's not used anywhere in code - Fixes some PInvoke signatures in DxtWrapper

anthony-linaro

A quick initial pass, just based on a read through

sources/native/Stride.Native.targets

anthony-linaro · 2025-02-18T10:14:53Z

sources/native/Stride.Native.targets

    <MSBuild Projects="$(MSBuildThisFileDirectory)WindowsProjects\WindowsDesktop\WindowsDesktop.vcxproj" Targets="Build" Properties="StrideNativeOutputName=$(StrideNativeOutputName);StrideNativeOutputDir=$(StrideNativeOutputPath)\runtimes\win-x64\native;StrideDependenciesDir=$(MSBuildThisFileDirectory)..\..\deps\;StrideNativePathLibs=libNativePath.lib $(StrideNativePathLibsWindows);StrideNativeProjectFolder=$(ProjectDir);StrideNativeProjectObjFolder=$(OutputObjectPath)\win-x64;Configuration=$(Configuration);Platform=x64" StopOnFirstFailure="true" />

+    <MakeDir Directories="$(OutputObjectPath)\win-arm64" Condition="'$(StrideNativeWindowsArm64Enabled)' == 'true'"/>
+    <Exec Condition="'%(StrideNativeCFile.Extension)' != '.cpp' AND '$(StrideNativeWindowsArm64Enabled)' == 'true'" Command="&quot;$(StrideNativeClangCommand)&quot; -gcodeview -fno-ms-extensions -nobuiltininc -nostdinc++ $(StrideNativeClang) -DNEED_DLL_EXPORT -o &quot;$(OutputObjectPath)\win-arm64\%(StrideNativeCFile.Filename).obj&quot; -c &quot;%(StrideNativeCFile.FullPath)&quot; -fms-extensions -DWINDOWS_DESKTOP -target aarch64-pc-windows-msvc" />


Excuse my unfamiliarity with the Stride3D codebase here, but have you tested this with clang?

If it works, it might even be beneficial to compile everything with clang, instead of MSVC, I found when I moved Blender builds to clang-cl instead of MSVC, I got a 46% perf improvement in rendering workloads.

I wanted to keep the changes arm64 related only. Modernising the native build chain would certainly be great but I believe that should be done separately. There are already attempts to so, for example one using zig which in turn uses clang.

Yes I think we need another issue for it.

archanox · 2025-02-18T11:28:14Z

Awesome job on picking this up again after I unceremoniously gave up.
Looks like you actually did the bits with the precompiled build artifacts successfully, which were too daunting for me due to how inconsistent it was.
Ideally it would be all built as part of the entire build process as to avoid future issues with additional platform bring-up.

I know my attempt was pretty messy, but hopefully there was something worthwhile to be taken from it, in particular the strange arm64 msbuild registry location.

Probably introduced by ddc7423

azeno · 2025-02-18T12:09:22Z

While trying to get a grip on the build error of the Visual Studio package on teamcity:

Did a console build locally ( msbuild Stride.VisualStudio.sln /v:m /m /nr:false /p:StrideSkipUnitTests=true /restore) and saw that one invocation of Stride.Core.Tasks was using a wrong path. See my commit above for details.
After that it was building fine locally. However on teamcity it's failing with a different error at MSBuildLocator.RegisterDefaults() in Stride.Core.Tasks - anyone any idea what's going on there?

Kryptos-FR · 2025-02-18T12:51:56Z

Did you try to build on Linux or Windows? It's ok to fail on Linux because those package are for Visual Studio which is Windows-only.

sources/tools/Stride.VisualStudio.Package.Tests/Stride.VisualStudio.Package.Tests.csproj

azeno · 2025-02-18T13:11:03Z

Turns out the Visual Studio update removed .NET 8 on the build machine. @xen2 just re-installed it, should be ok now.

archanox · 2025-02-24T14:18:10Z

@azeno is there anything that I can help with?

Are we in a position to update vstools? If so, I believe we can consolidate the references to the one version iirc.

How far did you get with getting the launcher and editor to build and run?

azeno · 2025-02-25T10:52:54Z

Basically waiting that the PRs in the other repos get accepted. Once that happens I can update this one again with the correct URLs/commit ids.

Editor is working. Asset compiler also. Like I wrote in the description, it's only one library for which there's no arm64 version.

azeno · 2025-03-04T12:01:31Z

@xen2 Thanks for merging the external repos. Once NativePath is merged (I've modified it based on your comment) I'll put this PR out of draft state.

deps/freetype/checkout.bat

azeno · 2025-03-04T13:25:23Z

Updated the checkout scripts once more, I think all external changes are now documented. Moving out of draft state.

anthony-linaro · 2025-03-04T17:12:46Z

Coming in as somebody who has never used Stride before - a few things (if I'm wrong, please correct me)

First:
When I follow the instructions on the main README (which I have been blindly following), I get this:

C:\WoA\stride\build>msbuild /t:Restore /p:Configuration=Release Stride.sln
MSBuild version 17.12.12+1cce77968 for .NET Framework
Build started 04/03/2025 13:56:04.

Project "C:\WoA\stride\build\Stride.sln" on node 1 (Restore target(s)).
C:\WoA\stride\build\Stride.sln.metaproj : error MSB4126: The specified solution configuration "Release|arm64" is invalid. Please specify a valid solution configuration using the Configuration and Platform properties (e.g. MSBuild.exe Solution.sln /p:Configuration=Debug /p:Platform="Any CPU") or leave those properties blank to use the default solution configuration. [C:\WoA\stride\build\Stride.sln]
Done Building Project "C:\WoA\stride\build\Stride.sln" (Restore target(s)) -- FAILED.

Adding the "Any CPU" config via /p:Platform="Any CPU" seems to work (though should the instructions say that? Or does there need to be some extra detection around ARM64 for this?) - looks like they restore okay.

Second:
There are a lot of hardcoded RuntimeIdentifier properties set to win-x64 - now most of these look to be in tests, which I assume is fine, but shouldn't everything be ARM64? I had a series of warnings pop up about mixed architectures when I built it. Doing a straight find-and-replace for win-arm64 seemed to fix those warnings, and give me a full ARM64 build of everything.

I ran a few of the tests, and tried a sample project/game which compiled okay and ran natively as ARM64.

Kryptos-FR · 2025-03-04T17:29:15Z

@anthony-linaro as far as I understand it, runtime identifiers have no impact on non-executable project (i.e. libraries). It only matters for executables (such as the tests).

I'm actually adding linux-x64 to some of those tests. This PR should add win-arm64 as well but not replace or remove win-x64.

So basically, it should go from:

<Project>
  <PropertyGroup>
    <RuntimeIdentifier>win-x64</RuntimeIdentifier>
  </PropertyGroup>
</Project>

to:

<Project>
  <PropertyGroup>
    <RuntimeIdentifiers>win-arm64;win-x64</RuntimeIdentifiers>
  </PropertyGroup>
</Project>

Note that RuntimeIdentifier (singular) becomes RuntimeIdentifiers (plural).

xen2 · 2025-03-13T00:31:24Z

deps/NativePath/checkout.bat

 %GIT_CMD% clone https://github.com/stride3d/NativePath ../../externals/NativePath
 IF NOT ERRORLEVEL 0 PAUSE
+pushd ..\..\externals\NativePath
+%GIT_CMD% checkout e615840e57ea80ce30b9e9f29f5fd84ca9b4b253


azeno · 2025-03-16T23:36:31Z

@Kryptos-FR @Jklawreszuk Please tell me if there's anything missing or you need more info to be able to merge this PR.

Eideren · 2025-03-29T14:16:10Z

Thanks !

Add requirement for ARM

Kryptos-FR reviewed Feb 16, 2025

View reviewed changes

deps/FFmpeg/dotnet/build.sh Outdated Show resolved Hide resolved

Kryptos-FR reviewed Feb 16, 2025

View reviewed changes

sources/core/Stride.Core/Native/NativeLibraryHelper.cs Outdated Show resolved Hide resolved

Kryptos-FR reviewed Feb 16, 2025

View reviewed changes

Jklawreszuk reviewed Feb 16, 2025

View reviewed changes

azeno force-pushed the feature/win-arm64 branch from 11c7e9e to 6ceecf7 Compare February 17, 2025 17:34

azeno mentioned this pull request Feb 17, 2025

WIP: Windows on Arm support #2397

Closed

8 tasks

azeno force-pushed the feature/win-arm64 branch from 6ceecf7 to aa6e55c Compare February 17, 2025 18:03

Kryptos-FR requested a review from xen2 February 17, 2025 18:17

anthony-linaro reviewed Feb 18, 2025

View reviewed changes

Fixes build of Stride.VisualStudio.sln

be055c8

Probably introduced by ddc7423

Kryptos-FR reviewed Feb 18, 2025

View reviewed changes

sources/tools/Stride.VisualStudio.Package.Tests/Stride.VisualStudio.Package.Tests.csproj Show resolved Hide resolved

Removes ARM64 from UWP

ead2b79

Kryptos-FR mentioned this pull request Feb 24, 2025

refactor: Nullable and Modernization for Core projects #2643

Merged

8 tasks

Kryptos-FR reviewed Mar 4, 2025

View reviewed changes

deps/freetype/checkout.bat Outdated Show resolved Hide resolved

azeno force-pushed the feature/win-arm64 branch from 9caef39 to 6cc218c Compare March 4, 2025 13:19

Updates checkout scripts of freetype and Bullet and NativePath

ea2ffcc

azeno force-pushed the feature/win-arm64 branch from 6cc218c to ea2ffcc Compare March 4, 2025 13:22

azeno marked this pull request as ready for review March 4, 2025 13:24

xen2 reviewed Mar 13, 2025

View reviewed changes

xen2 approved these changes Mar 13, 2025

View reviewed changes

Jklawreszuk approved these changes Mar 17, 2025

View reviewed changes

Eideren added the area-Build label Mar 29, 2025

Eideren changed the title ~~Adds native dependencies for win-arm64~~ feat: Adds native dependencies for win-arm64 Mar 29, 2025

Eideren merged commit 84f7fe5 into stride3d:master Mar 29, 2025
5 of 6 checks passed

Eideren pushed a commit that referenced this pull request Mar 29, 2025

Update README.md (#2692) following #2644

1925a7b

Add requirement for ARM

Doprez mentioned this pull request Mar 29, 2025

make default x64 and fix .dd imported files #2693

Closed

8 tasks

azeno mentioned this pull request Mar 30, 2025

fix: output directories of DxtWrapper and re-builds with MSVC v143 #2694

Merged

8 tasks

Uh oh!

feat: Adds native dependencies for win-arm64 #2644

feat: Adds native dependencies for win-arm64 #2644

Uh oh!

Conversation

azeno commented Feb 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Details

FFmepg

FreeImage

Recast

Needed PRs in other repos

Related Issue

Types of changes

Checklist

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

azeno commented Feb 17, 2025

Uh oh!

anthony-linaro left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

archanox commented Feb 18, 2025

Uh oh!

azeno commented Feb 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Kryptos-FR commented Feb 18, 2025

Uh oh!

Uh oh!

azeno commented Feb 18, 2025

Uh oh!

archanox commented Feb 24, 2025

Uh oh!

azeno commented Feb 25, 2025

Uh oh!

azeno commented Mar 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

azeno commented Mar 4, 2025

Uh oh!

anthony-linaro commented Mar 4, 2025

Uh oh!

Kryptos-FR commented Mar 4, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

azeno commented Mar 16, 2025

Uh oh!

Uh oh!

Eideren commented Mar 29, 2025

Uh oh!

Uh oh!

azeno commented Feb 16, 2025 •

edited

Loading

azeno commented Feb 18, 2025 •

edited

Loading

azeno commented Mar 4, 2025 •

edited

Loading