Modding, Mission Design, and Coding > Cross-Platform Development
FS2 Open native on Apple Silicon
Elyus:
I'm doing testing with an M1 Mac mini, and FS2 runs fine through Apple's Rosetta 2 translation layer, but I wanted to try a native build as well. I've seen discussion on these forums around ARM support for various other devices, and I'm happy to report that the code is 100% ready-to-go with Apple's arm64 implementation! There's just a couple caveats to keep in mind for anyone building an Apple binary right now:
* Libraries: the configure process still detects macOS and downloads prebuilt libraries into lib/prebuilt, but these are x86_64 versions
* SDL2.framework can be built natively directly from source.
* ffmpeg can also be built natively from source, although I followed this recommended simple configure as not all dependencies may be ported.
* Unlike sdl and ffmpeg, freetype can already be installed through native homebrew. However, whether by error in the brew formula or Apple's headers, it complains about some missing symbols in the bzip2 dependency. That's easy to fix with a new build from bzip2's code.
* During the build process, a few small issues and some Mac idiosyncrasies pop up:
* As mentioned above, freetype may try to link against the wrong libbz2 unless you've built a new one and added it to the linker flags.
* Also, libpng's NEON optimization is not ready for arm, so you'll need to disable it by defining PNG_ARM_NEON_OPT=0, per this discussion.
* Lastly, Apple signing... macOS has removed the option to run code from "Anywhere" and adhoc signing is no longer reliable in Big Sur. It's silly that I have to worry about signing an executable I just built, but I guess Apple wants all users to become very familiar with the `codesign` tool. Anyways, during `make`, the `embedfile` tool will fail to run until the adhoc signature is replaced, and once the final fs2_open app is built, you'll need to `codesign` the executable and all embedded libraries before it will run.
As you can see, it's just handling libraries and Apple signing. I expect everything will become simpler when homebrew supports more arm64 packages. In the meantime, I thought I'd share this in case anyone was curious about Freespace making the jump to Apple's new systems.
Now, the bad news. Unsurprisingly, the M1's integrated GPU isn't all that impressive in FS2. Benchmarks have indicated performance on par with some average laptop GPUs and some games are running quite well, so I would expect a little better, but I'm only getting 20-30fps in Freespace. Interestingly, Rosetta is only a little less than native, so Apple's graphics translation is quite fast. At any rate, while I'm satisfied with this performance on their very low-end chip, Apple is going to have to unveil some very compelling graphics technology if they truly want to drop discrete GPUs.
chief1983:
Were you running a mod with modern graphics or retail data? I'm curious if it was even running in hardware acceleration at all? Any chance you could run a fast debug build and provide a debug log?
Honestly adding native support to our build ecosystem for macOS is now just one more thing on top of the list of needs. It seems like every time one thing for mac is fixed, two more things manage to break before anyone can reap the benefits. I believe we no longer have an automated build pipeline at all for Macs now, thanks to losing TravisCI support. I still love my work Macbook but the ecosystem just keeps making things difficult.
m!m:
First of all, great work on getting FSO to run on the M1!
However, Apple is not making our life easier, that is certain. GitHub actions do have Mac support but that uses a later version of MacOS that already requires some of those code sign changes so I was unable to get that to work.
Even after all that, the deprecation of OpenGL basically means that at some point we will likely not have a graphics API to work with anymore. Judging from our current graphics development manpoower (which is basically only me) we are also not going to add Metal support.
All in all, I do not see the situation of FSO improving on Mac :sigh:
chief1983:
Actually that last one might not be a huge problem to overcome. https://moltengl.com/moltenvk/ seems to be a Vulkan to Metal translation layer, so if we do get Vulkan support, we could be translating one modern API to another one, and hopefully that remains a supported library.
m!m:
Well, MoltenVk requires us to first port to Vulkan though :P
And even then, we will need to find a Mac graphics developer to do the actual conversion since MoltenVk is not a complete reimplementation of Vulkan as far as I know so some changes will be necessary.
Finally, I would like to note that I am very reluctant to invest valuable time into supporting an OS that makes every effort to make the developers job even harder so at least for me Mac is very low on the priority list.
Navigation
[0] Message Index
[#] Next page
Go to full version