为什么Mac Pro性能这么强悍但是支持macOS的游戏却很少？
其实自从 Linux 那边通过 Proton 运行起来海量游戏之后，我就一直好奇为啥 Mac 没有吃到 Proton/Wine 的红利，x86 -> ARM 的转译应该很成熟了，大多数 3A ARPG 游戏是图形计算密集型应用，即便考虑 CPU 指令集转译损耗也不至于在 Mac 上跑不动。
今年四月因为升学缘故换了一台 M5 的 MBP，就开始着手研究。发现虽然大家都戏称“用 Mac 玩游戏是精神病”，但研究使用 ARM Mac 打 x86 Windows 的用户并不在少数，也有很多成熟的框架实现，有人数庞大的 macgaming 社区。然后我就发现，在 Mac 上通过转译打游戏，比我想象的复杂很多。
在 x86 Linux 上使用转译打游戏，我们只需要做好两层转换：
- Win32 API -> Linux syscall
- DirectX -> Vulkan（对于原生 Vulkan 的游戏，可以忽略）
因为 Valve 的加入，Proton 的推出，这两层转换的效率已经非常高了。对于很多游戏来说，性能损耗可以忽略不计。甚至因 Linux 系统可以裁切修改、占用更低的缘故，还经常能传出来 Linux 转译打游戏的性能超越同配置 Windows 的话题。
那么 macOS 能不能也走类似的路呢，答案是完全可以，但是要做的事情就很多了：
- Win32 API -> darwin syscall
- x86 机器码 -> ARM 机器码
- DirectX -> Metal
很多人下意识的以为这里面损耗最大的是指令集的翻译，然而 x86 <-> ARM 的相互翻译现在已经非常成熟了，Rosetta 2 在这方面做的不错，性能损耗十分可控，对于大多数图形密集型 3A 游戏来说并非是瓶颈。
真正的瓶颈在于 DirectX -> Metal。DirectX 和 Vulkan 都是显式 API，他们两个之间的转换很容易做。但 Metal 是高级抽象的设计，DX/VK -> Metal 就没办法用简单的结构化转换去搞定。甚至在 Apple 推出 D3DMetal 之前，社区中的 DirectX -> Metal 路线走的是：
DirectX -[DXVK]-> Vulkan -[MoltenVK]-> Metal
两层转译，性能损耗到天际了。即便 Apple 后来推出了 D3DMetal，解决了多层翻译问题，游戏的运行效率有着显著的提升，但也还是因为 Metal 和 DX/VK 的设计差异过大，每次 drawcall 都不能被高效批处理，进而导致整个管线的效率下降。图形密集型程序不能高效的进行画面绘制，就会导致帧数很快撞到天花板，怎么也上不去。
很多人对此有不同观点，我也认同。我这里的讨论前提是「图形密集型游戏」，对于其他不同类型的游戏来说，性能瓶颈可能就完全不同。对于一些 CPU 密集型的 RTS、策略游戏来说，Rostta 2 的转译瓶颈会更加明显。
解决办法有两条：
- 让 macOS 支持 Vulkan：从 Asahi Linux 的工作来看，macOS 不支持 Vulkan 并非是硬件不支持，只是 Apple 没有实现 Vulkan 相关驱动代码。
- 让游戏为 Mac 单独开发：直接登陆 Mac 平台，不需要翻译也就没有损耗了。
前者是最好的解决办法，但也是最不可能的解决办法。Apple 特别喜欢封闭生态，Metal 就是 Apple 的 GPU 生态锁，放开对 Vulkan 的支持会削弱生态绑定，因为不光游戏可以去用 Vulkan，高性能计算也可以去用 Vulkan，那注定没人会再选择 Metal。这是 Apple 不想看到的，至少库克时代的公司战略不允许 Apple 这样做。
所以就只能是后者了，相当于把成本转嫁到开发者身上，让开发者为 Metal 单独做一次适配。但是结果如你所见，没几个开发者愿意这么做。越大的游戏项目越不愿意，如果立项之初就没考虑 Metal，之后再往上加就很难了。
其实最合适登陆 Mac 的是各种手游，他们已经登陆了 iOS 平台，有着完整的 Metal 支持。macOS 也支持直接运行 iOS、iPad OS App，稍微做一下适配就能上 macOS，但即便如此很多手游公司还是不愿意直接登陆 macOS 平台，和几乎没人做 Linux 原生游戏一样，这是一个钱少事多的行为。
我个人觉得如果苹果真的有诚意去搞游戏生态，至少在 GPTK 内部单独实现一套 Vulkan 驱动，让游戏能在 macOS 上以 Vulkan 原生运行。否则大型 3A 游戏还是很难登陆 macOS，只能抱着手游移植和轻量级休闲游戏的生态玩了。