Current State Mac (June/2020)

[Valkyrie_Lenneth]

How do you quantity my cpu to be weak ? If you read other post, they still encounter sluggish problems with the later model of Mac

Its a dual core low power model. Mostly meant for web browsing and light tasks.

[Packetdancer]

To the OP: I play on the Mac Client with an eGPU, and while it doesn't run as nice as it does on Windows, I get enough performance that I'm satisfied with it. I think the only way we'll see improvements is if the 3rd party WINE provider somehow better supports Metal in Mac OS. Maybe if SE decides to rebuild FFXIV in the future, they'll select a platform that has more tools available for making cross platform games where they don't have to rely on a WINE wrapper. Fingers crossed.

As of the version that supports Catalina, I'm pretty sure the macOS version does support Metal instead of being atop OpenGL. It's just taking a somewhat roundabout method to get there. (DirectX goes through DXVK to be translated into Vulkan API calls, the resulting Vulkan calls go through MoltenVK to be translated into Metal API calls, and then Metal is actually executed.) It makes sense, inasmuch as WINE now uses DXVK so that any DirectX software can take advantage of Vulkan, so building the macOS version atop the existing MoltenVK translation layer rather than writing an entire new DirectX-to-Metal translation makes obvious sense.

The shift to that tower of translation layers is seemingly why the client performs (slightly) better on machines with discrete graphics than it used to, but can no longer run properly on anything using integrated Intel Iris Pro graphics; in a (very cursory) examination of the Crossover bottle in action, MoltenVK atop Metal on the Iris Pro GPU seems only able to emulate Vulkan 1.0, while DXVK seems to require Vulkan 1.1 to function properly.

[ErwinSchrodinger]

As of the version that supports Catalina, I'm pretty sure the macOS version does support Metal instead of being atop OpenGL. It's just taking a somewhat roundabout method to get there. (DirectX goes through DXVK to be translated into Vulkan API calls, the resulting Vulkan calls go through MoltenVK to be translated into Metal API calls, and then Metal is actually executed.) It makes sense, inasmuch as WINE now uses DXVK so that any DirectX software can take advantage of Vulkan, so building the macOS version atop the existing MoltenVK translation layer rather than writing an entire new DirectX-to-Metal translation makes obvious sense.

The shift to that tower of translation layers is seemingly why the client performs (slightly) better on machines with discrete graphics than it used to, but can no longer run properly on anything using integrated Intel Iris Pro graphics; in a (very cursory) examination of the Crossover bottle in action, MoltenVK atop Metal on the Iris Pro GPU seems only able to emulate Vulkan 1.0, while DXVK seems to require Vulkan 1.1 to function properly.

Seems plausible. I guess all of those translation steps result in a very poorly optimized experience.

I don't know what engine SE uses for FFXIV (proprietary: Luminous?), but several popular ones support Vulkan, and by extension would support MoltenVK, right? I'm sure I'm trivializing the amount of work needed, but wouldn't it be relatively easy to port a game if they were using an engine that supports multiple API's out of the box? Would seem to make sense in bringing it to more platforms and opening it up to a larger audiences imo.

[reiichi]

With Apple's recent announcement they're moving their entire platform to their custom ARM chips, this should be getting a bit more interesting.

I imagine SE will not be making any major changes aside from waiting for WINE to ensure it's safely compatible with Rosetta 2 to translate x86 code while also running all of the DX -> OGL/Vulkan things too. I would not be surprised if we see instances of "FFXIV cannot be run on the newest Macbook" messages come the official release.

[Packetdancer]

I imagine SE will not be making any major changes aside from waiting for WINE to ensure it's safely compatible with Rosetta 2 to translate x86 code while also running all of the DX -> OGL/Vulkan things too. I would not be surprised if we see instances of "FFXIV cannot be run on the newest Macbook" messages come the official release.

You are probably correct. Still, I think if there was ever a time to consider a truly native app without any sort of translation wrapper a'la Crossover/WINE, it would be now.

The engine already has to support GSMX (or maybe GSM, but I would bet on it being GSMX) for the PS4 client, and presumably once upon a time supported GCM (or PSGL?) for the PS3 client, as well as at one point supporting both DX9 and DX11 simultaneously, so there must be an abstraction layer in there for the graphics. In which case, adding support for Vulkan to that abstraction layer would mean that a) you could compile the client atop MoltenVK and have a Metal-driven native client for macOS, and b) you could theoretically target Linux systems with Vulkan support as well. Heck, you could even in theory target iOS (through the iOS version of MoltenVK) and Android (via Android's Vulkan support), and make a version that would run natively on the Apple TV or sufficiently-powerful Android TV boxes (i.e., the Nvidia Shield TV).

The trick is that the macOS version would probably need to draw more from the PS4 version than the Windows one in other areas; PS4's "Orbis" operating system is derived from FreeBSD, and macOS's userspace derives from FreeBSD as well. But Orbis has diverged in a number of places and has custom functionality that wouldn't exist on macOS or Linux/BSD systems. Add to that the fact that while older versions had to have been processor-agnostic (i.e., back when PS3 was supported), there's no guarantee they aren't using assembly blocks in the code to speed up processing of certain tasks; the PS4 is an x86-64 architecture a'la Windows PCs (and current Mac hardware), and if they have blocks like that in there, that'd be an obstacle to porting to ARM-based systems.

So it wouldn't be a simple task, but it's still feasible given an investment of time (and money, since time = money when it comes to paying programmers' salaries). And since Apple's making this move, it seems like it might not be a bad idea. Especially as Apple may not be the only one to take the plunge and shift to an ARM-based chipset in the long-term; the Intel x86 architecture is sort of hitting a wall when it comes to performance gains, while ARM chips are still improving efficiency at a fairly rapid pace...

Though sadly, I imagine if there's any major new platform support to be added to the Luminous Engine, it'll be added to Luminous Engine 2.0 (i.e., what powers FFXV—and maybe the upcoming Project Athia, based on rumor) rather than the weird offshoot version of Luminous Engine 1.0 that powers FFXIV.

So I suspect you are right, and they won't make any moves until they see whether WINE (or more specifically, Crossover) works well under Rosetta 2. :/

[reiichi]

The trick is that the macOS version would probably need to draw more from the PS4 version than the Windows one in other areas; PS4's "Orbis" operating system is derived from FreeBSD, and macOS's userspace derives from FreeBSD as well. But Orbis has diverged in a number of places and has custom functionality that wouldn't exist on macOS or Linux/BSD systems. Add to that the fact that while older versions had to have been processor-agnostic (i.e., back when PS3 was supported), there's no guarantee they aren't using assembly blocks in the code to speed up processing of certain tasks; the PS4 is an x86-64 architecture a'la Windows PCs (and current Mac hardware), and if they have blocks like that in there, that'd be an obstacle to porting to ARM-based systems.
/

Gonna focus only on this part because I'm in general agreement with everything else.

While Darwin does hail from BSD roots, the overlap with actual BSD when it comes to anything graphical is basically nonexistent as Apple's frameworks are nothing like what you'd get out of something more generic. It's fine for dev/cli stuff, but that's about where compatibility ends. But even on that note, the kernels are completely different and even projects like porting a BSD driver over to macOS is a monumental task, like the projects for intel wifi cards.

I'd imagine they can probably compile for general platforms, but that there's nothing currently done to target Vulkan, let alone Metal in their Luminous-ish Crystal Tools+ fork. So at a minimum, we're likely to still see DirectX calls being converted over, but that's honestly not super horrible overhead when you consider some games on DXVK are performing better on Linux than natively on Windows.

So there's maybe a chance we'll see a future version of the Mac port maybe being a weird amalgamation of Windows client bases compiled with WineLib. ...but most likely, we'll see WINE/Crossover getting custom x86 to ARM support if Rosetta 2 doesn't perform well enough or when it's eventually dropped in like 2 years. It wouldn't be the first time as the ancient DarWINE project had x86 to PPC for pre-Intel Macs with varying success.

[Packetdancer]

While Darwin does hail from BSD roots, the overlap with actual BSD when it comes to anything graphical is basically nonexistent as Apple's frameworks are nothing like what you'd get out of something more generic. It's fine for dev/cli stuff, but that's about where compatibility ends. But even on that note, the kernels are completely different and even projects like porting a BSD driver over to macOS is a monumental task, like the projects for intel wifi cards.

Sure, which is why I focused on Vulkan for the graphical stuff; you can map Vulkan to Metal (Apple's graphical API) via MoltenVK. (And the kernel is, as you rightly point out, completely separate; Darwin uses Mach as the basis of its kernel, and just takes the userspace and general library APIs from FreeBSD.) Where I meant the BSD similarities were for things like general system APIs; saving off configuration files, dealing with timers, networking APIs, etc. The Windows client likely uses Win32 APIs for that, but the PS4 Orbis system uses standard FreeBSD APIs for that and so the PS4 version likely uses those APIs, and those are available on macOS.

I.e., a translation/port would want to take the DirectX graphics layer (since you can do DirectX -> DXVK -> Vulkan -> MoltenVK -> Metal, and there's no similar GSMX -> Metal translation path that I'm aware of) or write a native Vulkan one (longer-term) to pick up Linux and then use MoltenVK directly, but probably would have less work if it took the PS4 filesystem/networking layers. Because while the kernel drivers for WiFi would be very different between FreeBSD and macOS, the actual networking calls in a userspace application are the same.

So I think we're actually on the same page there.

[justinhuang]

With Apple's recent announcement they're moving their entire platform to their custom ARM chips, this should be getting a bit more interesting.

I imagine SE will not be making any major changes aside from waiting for WINE to ensure it's safely compatible with Rosetta 2 to translate x86 code while also running all of the DX -> OGL/Vulkan things too. I would not be surprised if we see instances of "FFXIV cannot be run on the newest Macbook" messages come the official release.

Indeed. I watched the presentation and I’m also interested in what this transition change Mac version in the future. Whatever the case may be I hope it improve what we have now.

I am also having neutral thoughts on these transition. We saw other companies transition to ARM as well but much of it was not successful. Regardless, as long as it doesn’t affect my day to day tasks, and hopefully not ffxiv, I don’t mind the transition that much.

[pizzy]

I also run a mac with an eGPU My system is a late 2015 iMac, I also was experiencing issues with FPS as well as notices some graphical issues occasionally.

I started messing with the settings and under the Graphics settings, I turned the "Glare" off. By turning that off I am now running between 55 to 65 FPS and no more graphic issues. I was running in the low 40's prior to turning that off.

Maybe this will help you increase performance?

Cheers!

[EggySong]

Square Enix ought to consider just building a full-fledged port for Apple silicon. Not only will it future-proof the game for Macs moving forward, but will also likely improve the experience significantly for intel-based macs running Big Sur or later. Not to mention open a pathway onto iOS devices.
Even starting with an iOS port and working it up to Mac via catalyst would give us something that would just work.