ARM64 Linux support officially
theofficialgman opened this issue · comments
Was able to build an run on ARM64 linux (test system Nintendo Switch). Needed to download the ARM64 binaries from FMOD and build FostFramework/Foster from source (see the github actions there for simple build commands) and place the files manually but otherwise it works well.
Hope that official ARM64 and ARMhf Linux builds can be made (since FMOD supports both and that is the limiting factor)
Hey, that's awesome! Yeah I think the main blocking thing on that right now would be the github action in foster that builds the native libs. If that can be modified to also do ARM64 linux builds I'm happy to include it.
@NoelFB actually cross compilation seems to work quite easily with your library
install the cross compilers from apt and prepend the CC and CXX variables to use them.
you will also need some additional arm64/armhf -dev libraries but those can be installed pretty simply too
eg: https://github.com/shiftkey/desktop/pull/897/files
the only package that I had to personally install from arm64/armhf was libsdl2-dev:arm64 and libsdl2-dev:armhf which pull in everything else automatically
I made a little hacky commit in my fork of your repo here -> theofficialgman/Foster@740456e
as you can see from the successfull CI run and push to the repo https://github.com/theofficialgman/Foster/actions/runs/7721171147 it creates a functional arm64 binary. I will leave it up to you for integration. You should be able to mostly follow the first link I sent. boht armhf and arm64 should be doable in the same manner. I will note, if you look in the logs you can see that some of the SDL2 optional features aren't enabled (eg: wayland, pipewire, and pulseaudio). Those probably require additional libraries that are just normally preinstalled in github actions ubuntu for amd64 and aren't pulled in by libsdl2-dev itself. You should compare what your library takes advantage of in SDL2 and add any additional libraries as necessary.
I checked with celeste64 and this binary works well including audio... I guess it uses ALSA in Foster/SDL2 or FMOD for audio.
I've updated to Foster 0.1.16 which has libarm64 now for Linux ... I think the only thing that needs to change now is this part of the .csproj?
<ItemGroup Condition="($(RuntimeIdentifier) == '' and $([MSBuild]::IsOSPlatform('Linux'))) or $(RuntimeIdentifier) == 'linux-x64'">
<Content Include="Source/Audio/FMOD/libs/lib64/**" CopyToOutputDirectory="PreserveNewest" Link="%(Filename)%(Extension)" />
</ItemGroup>I'm not sure how to handle it exactly though. Right now it copies lib64 if you're running from linux without a RuntimeIdentifier, but this will need to change I think. We basically want something like:
<ItemGroup Condition="($(RuntimeIdentifier) == '' and $([MSBuild]::IsOSPlatform('Linux-x64'))) or $(RuntimeIdentifier) == 'linux-x64'">
<Content Include="Source/Audio/FMOD/libs/lib64/**" CopyToOutputDirectory="PreserveNewest" Link="%(Filename)%(Extension)" />
</ItemGroup>
<ItemGroup Condition="($(RuntimeIdentifier) == '' and $([MSBuild]::IsOSPlatform('Linux-Arm64'))) or $(RuntimeIdentifier) == 'linux-x64'">
<Content Include="Source/Audio/FMOD/libs/libarm64/**" CopyToOutputDirectory="PreserveNewest" Link="%(Filename)%(Extension)" />
</ItemGroup>But I don't think these actually exist for IsOSPlatform.
I think with #49 this should now be working?
I think this should be working, the only remaining issue I see is updating the build action to also include the arm version: https://github.com/ExOK/Celeste64/blob/main/.github/workflows/build.yml
yup can confirm building locally works on arm64 linux well
specifically using dotnet publish -c Release -r linux-arm64 -p:ImportByWildcardBeforeSolution=false -o build to get a tuned release build
For the tuned release build, the screen goes to black after the logo spins ~180 degrees on Asahi Fedora Remix. Controls all work, but the screen stays black from then on. That holds true for just building locally with -c Release and with the proposed build action PR, so I don't think it's any reason to hold up the PR.
I'm going to try and see if I can narrow down the issue tonight, if it hasn't already been resolved by then.
Edit: For further context, have had no issues when running the debug build.
no issues on my end. also got ARM32 linux build done
Actually, will the ARM32 ones work since Foster is built only for 64 bit architectures?
Actually, will the ARM32 ones work since Foster is built only for 64 bit architectures?
see FosterFramework/Foster#62 and the message #64 (comment)
For the tuned release build, the screen goes to black after the logo spins ~180 degrees on Asahi Fedora Remix. Controls all work, but the screen stays black from then on. That holds true for just building locally with
-c Releaseand with the proposed build action PR, so I don't think it's any reason to hold up the PR. I'm going to try and see if I can narrow down the issue tonight, if it hasn't already been resolved by then. Edit: For further context, have had no issues when running the debug build.
actually I do see one or two graphical glitches on the menu when using the release build. the forsaken city picture goes away after it finishes moving into place and the letter is transparent. but otherwise I haven't encountered any problems.
to add to that, glass does not break (the character just phases through it)
I do not see this problem on x64 when building in the same manner
Is this for ARM in general or only the 32-bit ARM?
Is this for ARM in general or only the 32-bit ARM?
@NoelFB
Ok to summarize the issue.
On -r Release builds on ARM64 (testing on Raspberry Pi 5 (MESA) and Nintendo Switch (Nvidia proprietary)) there is a chance that the screen will go black on the logo and never recover (@andymandias so yes I was able to recreate your issue). This is rare for me.
Additionally, if the screen does not go black, the character can phase through glass, the letter is transparent, and the forsaken city picture goes away after it finishes moving. The issue is independent of cross compiling in CI (eg: from x64) or compiling on ARM64 natively locally.
These issues do not happen on -r Debug builds on ARM64.
These issues are not observed on ARM32 or x64 Linux
@NoelFB I have "limited" the issue down to the difference between Optimize flag being enabled vs disabled https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/compiler-options/code-generation#optimize
In Release, optimize is enabled by default. In Debug, it is disabled by default. Changing the option in either configuration changes the result (eg: Debug with optimize enabled has the issues and Release with optimize disabled does not have the issues). That is unfortunate because optimization does produce a noticeable speedup on many weak CPU bound systems. Do you think this is a compiler bug and do you have any ideas of submitting a bug report upstream with a more simplified testcase?
Interesting! I wonder if this is tied to the segfault happening on MacOS. When I was able to test on a mac we were getting issues that sounded very similar (logo doing a 180 and then disappearing).
Unfortunately I don't have a great way to test this on my end ... It's possibly an issue with .NET 8, but I'm curious as to what it would be. It might be some kind of floating point math precision/rounding issue? I would likely need to open a debugger and step through code to see if I can figure out why things like the logo/card stop rendering, or why glass is suddenly not solid.
I don't know much about .NET/C#, but it seems like the debugging options are limited since the bug(s) only reliably appear with optimization on. I can get a black screen every time with optimization on, but never with it off (so far).
Just playing around with simple prints I was able to get the game to load without going to black by setting FromBlack to null on line 65 in Startup.cs. But getting past the screen going to black, then I wind up seeing all the issues @theofficialgman mentioned (clipping through glass, forsaken city card disappearing, etc). Feels like a memory issue to me, and I expect it's not directly related to the workaround I found.
I made progress on this but it makes no sense. Something is wrong with the .NET Vector Math sometimes... #70 (comment)