[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

[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

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.

[chief1983]

Yeah I know it's not ideal, but I also know of mod and SCP contributors who are still primarily Mac users so I'm wary of giving up on it entirely.

[Elyus]

@chief1983, that's a good point about graphics acceleration.  I'm not sure, but I did create a FASTDBG build and flew around the first mission a bit.  The fs2_open.log is attached; it's using the current mediavps and some custom flag presets from an old version of the launcher.

It does appear there's an error acquiring an OpenGL context.  It's true as @m!m points out, Apple's deprecation of OpenGL is problematic in that they're letting the supplied version languish while pushing developers to their Metal framework.  That said, the fact that they bothered porting OpenGL indicates they'll leave it around for some time, although undoubtedly it will receive little support and no updates.

I completely understand the concerns with handling macOS builds, but I am hoping things will begin to stabilize past this transition.  Apple's recent push to abandon legacy technologies has been focused on preparing for this transition.  Plus, with Apple, anything could happen.  They've been down the road with proprietary graphics frameworks before: QuickDraw3D was the big thing before ditching it when they went to OpenGL; maybe they'll consider supporting Vulkan some day? 

[attachment deleted by admin]

[m!m]

At least the error I could find are "expected" on Mac since we try to create higher versions of OpenGL first starting with 4.5 and at 4.1 we finally get one.

Regarding their support, the main issue is that at some point we are going to use features exclusive to OpenGL 4.2 or higher at which point Mac becomes impossible to support. We had that situation before with fixed-function OpenGL and it was not pretty. If Vulkan or MoltenVk works at that point it will not be an issue but that is a big "if".

[jg18]

@Elyus: nice work.

That said, things aren't looking rosy for future Mac support....

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.

Unfortunately, I'm inclined to agree. Although I've recently done some work to improve Mac support, it looks to me like Apple is intentionally moving away from cross-platform compatibility. Even if we can find a coder willing to dedicate themselves to Mac support, there's a limit to how much the SCP can bend over backwards to support an OS whose developer has shown no interest in making cross-platform support easy.

It's ironic, in that Microsoft is moving towards cross-platform with things like Hyper-V and the new .NET. Ah, well.

Yeah I know it's not ideal, but I also know of mod and SCP contributors who are still primarily Mac users so I'm wary of giving up on it entirely.

Yeah, I was a Mac user when I joined SCP and I doubt we'll give up on it entirely. But Mac support is bound to get worse over time, and even with good intentions, the SCP can't do a whole lot about it.

[ShivanSpS]

Actually, the performance is not too bad for the M1. Specially if you are talking about 1080p, AMD Vega 11 is not that much faster really.

What i do find interesting is that you were able to run mediavps on the M1 on arm64 with the unaligned models and shields system not causing crashes, i really had to solve quitte of a few issues to do that on the RPI, it looks like Apple handles that a lot better.

[The E]

Actually, the performance is not too bad for the M1. Specially if you are talking about 1080p, AMD Vega 11 is not that much faster really.

What i do find interesting is that you were able to run mediavps on the M1 on arm64 with the unaligned models and shields system not causing crashes, i really had to solve quitte of a few issues to do that on the RPI, it looks like Apple handles that a lot better.

The M1 does include some special bits for memory access in order to speed up x86 emulation, I think that may be the reason why?

[ShivanSpS]

Yeah, i guess they really had to ensure the CPU could properly handle that. It could also be their kernel, the linux kernel actually does a good job in fixing some of the unaligned memory access, because if i disable the unaligned access fixing in linux, FSO will still crash in... i think it was the scripting area.