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

@@ -515,10 +515,10 @@ internal class Utilities
        [DllImport("DxtWrapper", CallingConvention = CallingConvention.Cdecl, CharSet = CharSet.Unicode), SuppressUnmanagedCodeSecurity]
        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

@@ -138,6 +144,11 @@
    <Exec Condition="'%(StrideNativeCFile.Extension)' == '.cpp'" Command="&quot;$(StrideNativeClangCommand)&quot; -gcodeview -fno-ms-extensions -nobuiltininc -nostdinc++ $(StrideNativeClangCPP) $(StrideNativeClang) -DNEED_DLL_EXPORT -o &quot;$(OutputObjectPath)\win-x64\%(StrideNativeCFile.Filename).obj&quot; -c &quot;%(StrideNativeCFile.FullPath)&quot;  -fms-extensions -DWINDOWS_DESKTOP -target x86_64-pc-windows-msvc" />
    <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.

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

Draft

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

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Adds native dependencies for win-arm64 #2644

Adds native dependencies for win-arm64 #2644

azeno commented Feb 16, 2025 •

edited

Loading

Kryptos-FR Feb 16, 2025

azeno Feb 16, 2025

Jklawreszuk Feb 16, 2025

azeno Feb 16, 2025

Jklawreszuk Feb 16, 2025

azeno commented Feb 17, 2025

anthony-linaro left a comment

anthony-linaro Feb 18, 2025

azeno Feb 18, 2025

Kryptos-FR Feb 18, 2025

archanox commented Feb 18, 2025

azeno commented Feb 18, 2025 •

edited

Loading

Kryptos-FR commented Feb 18, 2025

azeno commented Feb 18, 2025

Adds native dependencies for win-arm64 #2644

Are you sure you want to change the base?

Adds native dependencies for win-arm64 #2644

Conversation

azeno commented Feb 16, 2025 • edited Loading

PR Details

FFmepg

FreeImage

Recast

Needed PRs in other repos

Related Issue

Types of changes

Checklist

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

azeno commented Feb 17, 2025

anthony-linaro left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

archanox commented Feb 18, 2025

azeno commented Feb 18, 2025 • edited Loading

Kryptos-FR commented Feb 18, 2025

azeno commented Feb 18, 2025

azeno commented Feb 16, 2025 •

edited

Loading

azeno commented Feb 18, 2025 •

edited

Loading