Apple's hardware is unquestionably very good now, and their graphics APIs are actually seeing some uptake. The recent stories about Resident Evil Village especially sound positive.
> The main Proton issue is that it runs on DXVK, and MoltenVK is not always up to parity with implementing Vulkan API calls on Metal reliably.
https://github.com/ValveSoftware/Proton/issues/1344#issuecom...
An alternative would be using CrossOver (which pulls from Wine and adds stuff like MoltenVK), which is what Proton does as well (pulling from Wine and adding stuff, but not MoltenVK) and vendors internally, Valve "just"† doesn't pull from the CrossOver changes nor expose Proton on macOS.
† scare quotes because it may not be as easy as it seems
https://hypertexthero.com/mac-video-games-for-streaming/
I try to keep it updated and suggestions are always welcome.
I would not really care if my game library was going through Rosetta 2, as I'd rather take a theoretical performance hit (vs a native arm64 build) than outright be unable to play.
This kind of attitude just isn't conducive for gaming, where people like to build libraries in steam and expect everything to keep working for a long time.
On my PC, I can fire up games from 20 years ago and they work perfectly. Witcher 3, a 7 year old game, is getting an overhaul. I expect no problems in downloading it on steam from my library and playing it seamlessly on my relatively new PC.
IIRC win64 finally killed win16 support but that was rarely used for games and those games you can dosbox (which amusingly enough works fine on Mac in many cases).
They quote around 200 UPS average. It's hard to compare to the linked benchmarks because those quote p75 numbers instead of average, but it seems like the results are in the same general ballpark as the Ryzen 9 5950x.
0. https://factoriobox.1au.us/results/cpus?map=4c5f65003d84370f...
I think that the 13700k and 13900k with the same turbo ratio should perform almost the same in gaming workloads. The only difference should be in the 36 MB of LL cache vs. 30 MB. It's a modest difference, but factorio is memory subsystem performance sensitive.
I'll add a benchmark to that page in a few days with a 5.8 GHz clocked 13700k to test the theory.
I'm looking forward to your test results though as I'm considering building a new desktop around 13th gen.
I've been experimenting with different settings and found that unlimited PL2 and undervolting the CPU by -150mV give the best temperature to performance at ~80c during full load. It has been running stable for few days, and I'm pretty happy with the result so far.
Also, those numbers aren't far off the out-of-box behavior I had, but I like to tinker. I throttle with PL set to 190 but not at 180.
That doesn't mean the 13700k can't match (or exceed) the out-of-box Factorio performance of the 13900k when given better memory, hence the score of 304 UPS.
https://factoriobox.1au.us/result/21784265-472e-4275-847c-dd...
Bonus: E-cores have thermal headroom at stock and can be stable at 4.5 GHz if given +0.1 V, but this cuts into the thermal headroom of the P-cores in all-core workloads and lowers the overall performance. Bumping to 4.3 GHz from 4.2 GHz with no voltage increase is stable.
FPS: Despite being a 2D sprite game, sometimes it has trouble keeping FPS at 60, at least when running at max graphics and max zoom level with a graphically intensive mod. I would guess it's using OpenGL, and Apple's OpenGL stack isn't great. You can see the article mentioning the M1 Max only hitting 45 FPS in one of the tests, and this is without mods (but with a huge base and presumably a wide zoom level). In my experience, if you adjust the graphics settings appropriately (eg max sprite atlas size and max vram usage, since integrated graphics use unified memory), you can usually keep it at a smooth 60 FPS 99% of the time even in graphically-intensive setups with max or almost-max quality settings.
UPS: Scoring 199 UPS on the flame_sla 10k base puts the M1 Max above any other laptop processor for that benchmark. This matches my experience: the simulation part of the game almost never lags, except for unavoidably heavy operations (eg generating new worlds when playing with mods that do that). See a comparison at:
https://factoriobox.1au.us/results/cpus?map=4c5f65003d84370f...
It puts it above an EPYC 7763! I presume it wasn't using all 64 cores though.
Rosetta 2 is not emulation, at all, it's AOT, static binary translation, backed by hardware that implements Intel specific behaviour from the latest chips down to the oldest 8080 or something. It's eerily fast.
In fact, it happens that arm64-translated x86_64 running on Apple Silicon can often be faster than x86_64 running on the latest Macs with Intel processors.
So you really have to ask two questions here:
- does the x86_64 Factorio build run faster on Apple Silicon than on a comparable† Intel?
- on Apple Silicon, does the arm64 Factorio build run faster than the x86_64 Factorio?
† whatever that means
So, it is hardware emulation.
Imagine you only speak English and you want to read a novel in French.
Emulation: you hire a translator to read the novel to you. They translate each word while reading.
Static translation: you hire a translator to transcribe the book from French to English. They give you a printed book purely in English. But simple French words like flâner and râler are expanded into lengthy passages because there is no simple English translation.
Rosetta 2: you hire the translator to transcribe the book to English, but they leave in unique French words and teach you what they mean so you can understand them in an English phrase without even noticing that the word isn’t “real” English.
Rosetta 2 isn’t emulation because no instruction is translated on the fly to a different ISA. It’s static translation plus ISA extensions. There is no lower level emulating anything.
It does have JIT translation (not a JIT "mode" though, as it always use AOT translation, only relying on JIT translation at runtime for the parts that need it)
> which is a bit more like conventional emulators
Not at all†, Rosetta 2 does the same†† translation step on dynamic Intel code, whose arm64 output can be reused afterwards
> But it's used infrequently, eg when dealing with x86_64 apps that themselves use a JIT
Yes, although it's more like "exceedingly rarely" in practice since usually those interpreters are up to date enough to have a native arm64 release.
See there for details: https://dougallj.wordpress.com/2022/11/09/why-is-rosetta-2-f...
† Unless you've been meaning dynarec, but I would not call that "conventional" although it is a well-known technique https://en.wikipedia.org/wiki/Dynamic_recompilation
†† IIUC minus a few things that can't be done when just-in-time because some assumptions are not guaranteed to be satisfied.
I could probably extend the metaphor to an avant garde French novel that asks the reader to look up and include today’s headlines from Le Monde, but it was already stretched.
> So, it is hardware emulation.
It's more like there's a full Intel CPU in disguise, only with instructions and registers having another name.
Building for ARM is probably not a big challenge if you’re already building for Apple’s x86 toolset.
Metal would be more of a challenge I imagine, but a bridge probably worth crossing all else being equal (or one that you don’t need to cross at all if you’re using something like unreal or unity).
The Mac isn’t a games platform as Apple hasn’t shown much interest in the mainstream gaming market, and I can’t imagine major publishers are eager to fork over a third of their revenue on the App Store for sales they’ll probably pick up elsewhere without more work and cost. Sure theres Epic and Steam on Mac, but they’re ghost towns, and publishers are likely waiting to see what way the EU Digital Markets Act shakes out globally anyway (as other governments are pressured to provide the same freedoms).
There was talk at one point of Apple working on a game console (a more powerful Apple TV) but who’s the market for that?
They’ll not be cost-competitive with Xbox or content-competitive with PlayStation and Nintendo.
At best they’d be likely to produce a similarly powered box with little content and a high price tag in a market already retailing hardware below cost price.
Honestly it doesn't matter. The whole "Macs can't game" has no basis in facts. The goalposts are continually moved.
To give some examples of arguments.
- Not enough games for it. There is actually more games in the Apple store than most other gaming stores. You can also play a lot of iOS games now.
- The majority of games are terrible. The majority of games in other stores are terrible too (sadly).
- It can't play [insert PC game]. Neither can a Nintendo switch but that doesn't mean it can't play games.
- I can play [insert PC game] but doesn't count because it's too old. You can't win on this one.
- It's not a real game unless it uses a GPU. There are countless games out there that don't meet this requirement.
Really the only argument for Macs not being gaming machines is that the majority of buyers do so not to play games on it, but to get stuff done.
Anyone who can afford a Mac is likely to have at least a console and/or PC Gaming rig.
The gaming industry will go where the money is.
The majority of the industry revenue is now on mobile and the lions share of mobile revenue is on iOS and Metal.
I think Apple Silicon Macs will end up benefiting from studios having experience with Metal on iOS in the same way that XBox benefited from studios having experience with Direct3D on Windows.
You have…
- App Store (OSX and many IOS)
- Steam
- Epic Store
- Blizzard Store
- Crossover and Parallels to do some windows games.
- Mame and it’s like exist.
- You even have free games on GitHub.
If you can’t find the games the issue isn’t with the Mac.
Having access to a lot of mobile games doesn't matter for hardcore gamers.
Your claim means that the Nintendo switch is not a gaming platform.
A AAA game is not denoted by how many platforms it releases on the first day.
Your other comment about mobile games is just another form of gatekeeping. Again the Switch is mobile gaming and would not meet your criteria.
I study Computer Engineering, so having a good laptop was important. Prior to this I owned refurbished ThinkPad running Linux which cost me around $500 but had multiple issues with performance and speed, to the point where buying an M1-class machine was almost necessary for me.
Android is following with 32-bit deprecation this year, actually. Pixel 7 doesn’t support 32-bit apps.
Metal came out in 2014, Vulkan in 2016.
Better for someone else to build a Vulkan API on top of Metal, which is what has happened. It's not perfect, but it's the only thing that can work. The pressure on Apple should be for Metal to better support Vulkan by providing APIs it needs to work optimally.
Beyond that, Apple might want to contribute to the Vulkan-on-Metal implementation... though they're only going to do that if it makes strategic sense, which I don't see. For cross-platform, what makes more sense is to encourage games to use a higher-level engine that supports metal among its platforms, like Unity and Unreal.
Typically, if a game maker wants to make cross-platform a priority, they wouldn't target just Vulkan, they'd target a cross-platform framework. That would be true whether Vulkan was supported by Apple or not. And if they don't make cross-platform a priority, the chances of a mac port go down regardless.
So...
We're looking at the incremental gain of Apple providing first-party support for Vulkan vs the existing third-party support. Looks like a lot of work for Apple for little gain. Just doesn't seem worth it to me. Also, the Vulkan version would always be out-of-date since Apple would pin the supported version to an OS release, and would need to be conservative about it, since they aren't going to hold an OS release for Vulkan.
Really, Vulkan on macOS is much better done by the interested third parties, and the focus on Apple should be to get them to better support a Vulcan API on top of Metal.
I'm confused. Your previous statement was saying the main point is that Apple have kept a bad API.
> Vulkan is what people are using and Vulkan can translate from DirectX. Apple is shutting themselves off from the rest of the industry with this move, which I would argue (judging by how many Mac users wish they could game) is a bad thing.
Possibly, FSVO translate, but I don't think anyone was commenting on this new point. More with the previous points.
When did the rest of the industry drop Direct3D for Vulcan?
The industry uses Direct3D on Windows and XBox, Metal on Mac and iOS devices, Gnm on Playstation, and Nvn on Switch.
Aside from a subset of Android, what popular platform uses Vulkan by default?
DXVK is currently only used as a drop in replacement for DX9 games. DX10 has been forgotten (thank god), DXVK's D3D11 implementation is not good, and more and more games are going on D3D12 which affords a hell of a lot of control.
Additionally, DirectX is not just a graphics API, it's also sound (XACT and XAudio2), ray tracing (DXR), Input handling (XInput & DirectInput), CUDA-like calculations (DirectCompute), storage handling (DirectStorage), etc. Most of these have either an alright equivalent (DXR has an equivalent in Vulkan with extensions, and that's about it, and Valve's input implementation is _really good_, but it's not a usable API as far as I know.) or a wildly inferior alternative (at least for the PC space that is Windows/Linux/MacOS). D3D12 also is one of the drivers of new GPU programming features in the PC space (once again, the console side of things is a bit weirder, although MS does bring some lessons in from the Xbox side of things), while Vulkan is kind of stuck doing everything as extensions that may or may not be available, and Metal is still a piece of shit.
So, yeah, no, DirectX is far from irrelevant.
Remember, to start, Windows only officially supports DirectX. OpenGL and Vulkan comes from your GPU vendor and Microsoft waives all responsibility for them. Vulkan is, quite literally, a 3rd-party API that can run on Windows - not something Windows supports or endorses.
Xbox does not support Vulkan. DirectX or get rejected.
Only 60% of Android devices support Vulkan. Guess you’ll also need ANGLE or OpenGL for backwards compatibility.
PlayStation does not support Vulkan. Better learn gnm, gnmx, and PSSL.
Nintendo Switch has Vulkan but it is almost unusably slow, on a console that is already not known for speed. Better use NVN if you want anything decent.
iOS does not support Vulkan. Better use Metal.
So… what does Vulkan support, exactly? Windows, Linux, and not enough of Android. If your game only runs on desktop, it’s a good option - but why not target DirectX? Windows, Linux with Proton, and most of the Xbox support all in one. For this reason, I have yet to see a Vulkan game that does not have a DirectX mode.
Blaming macOS for being proprietary is disingenuous in an industry full of Proprietary APIs.
Windows doesn't "support" the DirectX version shipped by your GPU vendor either. The drivers shipped by your GPU vendor, and all the APIs provided by them, are supported by your GPU vendor.
So the real thing we're talking about is hardware vendors. Nvidia and AMD support Vulkan, OpenGL, and DirectX where applicable. Apple only supports Metal. The console vendors have always had weird variant APIs based on the open standards but not identical, except MS where the console is very close to desktop Direct X.
On mobile hardware vendors ubiquitously support OpenGL ES and there's widespread support for Vulkan.
So it's complicated. In the desktop space, as a percentage of market share, Vulkan is extremely widely supported. Same with mobile. Consoles have always been an odd man out.
So Apple, which doesn't sell a console, is absolutely breaking from the pack in the markets they target.
If you consider 60% of Android users, and 0% of iOS users, "widely supported," sure. That's less than half of mobile phones in use right now, making Vulkan the odd-one-out on mobile as well. You certainly can't build a mobile app right now that only uses Vulkan without cutting out huge parts of your audience.
> So Apple, which doesn't sell a console, is absolutely breaking from the pack in the markets they target.
Apple wants the same API on all of their devices, and I can't blame them. They are the odd-ones-out in Desktop only.
But does that really matter? If you are making a game only for Desktop, namely Windows, and weren't going to just use DirectX for some reason, it does (which I think, nowadays, is a rare situation). But if you are targeting any game consoles, or any mobile phones, you're adding multiple graphics APIs anyway and Metal is just another one.
But that's what we're talking about, if it weren't for Apple Vulkan would be a near ubiquitous desktop and mobile API. Apple is the one standing in the way of that.
If Vulkan were a near ubiquitous mobile and desktop API, _maybe_ the console vendors would be more willing to tolerate it.
Ubiquitous desktop: Windows
Uniquitous gaming consoles: XBox and Playstation
Ubiquitous phones (worldwide): Android
APPLE IS RESPONSIBLE FOR VULKAN NOT BEING EVERYWHERE (not in Windows, not on XBox, not on Playstation, not on 40% of Android devices)
Sony only cares about their console(s), so they prefer to focus on optimization rather than compatibility. (While Nintendo cares more about gameplay than graphics.)
Isn't that 40% of Android devices old / very cheap ?
Apple is one of the biggest (and especially, most profitable) companies in the world, and with great power comes...
Because only Apple has the power and hence the responsibility, not the tiny helpless companies Microsoft and Sony (~99% of consoles, 76% of desktop).
Edit: don't forget, Apple absolutely must support Vulkan (and others don't) because Metal is proprietary and non-cross-platform (just like any other graphics API on all major platforms) even though Vulkan appeared two years later than Metal (but neither Microsoft nor Sony are expected to drop their APIs which also appeared earlier than Vulkan).
Did I get that logic right?
Total addressable market matters here. 100% of Android-based VR headsets support Vulkan. Granted, that's mostly the Quest 2, but it's not the only HMD in town anymore.
Also, a lot lot lot of Android devices are garbage-tier <$100 that you wouldn't want to target anyways because you won't get any sales on them. So the % of Android devices supporting Vulkan may be misleading in the sense that you might be aiming for a segment of devices with much, much higher, if not complete, support for Vulkan.
The business case on this was a slam dunk. Other companies running virtual product stores with similar terms would have done the same irrespective of how popular Epic's products were.
Digital Foundry did some review of MetalFX in Resident Evil Village[1] and was pretty positive about it. (From DF's findings, MetalFX has some problems with transparent texture, but details preservation/restoration are pretty good.)
At a technical level it seems like they could get more console-like levels of tuning for their platforms. Very few chips to support, only a handful of thermal targets, all chips have a common CPU/GPU architecture, all devices have very fast storage. Conceivably they could field a winning platform for competitive gaming.
My guess is they look at Sony & Microsoft and don't see much value in reshuffling priorities to likely just be #3.
Edit: hajile above convinces me that rather than concerns about spending money to be #3 they probably already are in the top few by gaming revenue and could have lots of reasons for not being more aggressive about taking more share.
That seems to be changing though as there are pretty strong supply chain rumors that they are working on AR/VR headsets (allegedly delayed due to terrible market conditions and some supply chain issues). They've also made pretty big investments into their subscription game service.
I think Apple TV is very overlooked by developers too.
There's a lot of processing power in those things. The weak 2021 model has 15% more GPU power than a docked switch (30% more than an undocked switch). The older 2017 model uses an X processor which should give it even more GPU power (almost double an undocked switch). The latest A15 model (with a major price drop vs the previous generation) has more GPU power than the Xbox One S and isn't so far off from the PS4.
Nintendo Switch 500 GFLOPS (docked) 390 GFLOPS (portable)
Apple TV (A10x) 770 GFLOPS (2017)
Apple TV (A12) 580 GFLOPS (2021)
Apple TV (A15) 1500 GFLOPS (2022)
Playstation 4 1850 GLOPSS
Xbox One S 1400 GFLOPS
Because no one nows if the platform will be there or not. Apple's commitment to it has been lackluster. And since there are no dedicated controllers, you'll need controllers from a system... that you probably already own, so why play on Apple TV?
1. https://appleinsider.com/articles/21/10/03/apple-earned-more... (15.9*0.69=11B)
2. https://www.microsoft.com/investor/reports/ar21/index.html (Gaming: 15,370)
Contrary to widespread opinion, Vulkan is not an industry standard. It’s a 3rd-party DirectX alternative for Windows, the best API for Linux, and a curiosity on Android. And that’s literally it, nothing else supports it (except Switch, but it is so slow, almost no games use it, opting for the proprietary NVN).
"Vulkan is not an industry standard" I mean yeah, in the same way Microsoft word is not an standard.
"except Switch, but it is so slow" again that seems to be a lie, doom eternal orks way, way better on it than it would be on similar software on a different API.
It is completely honest. On a fresh install of Windows, if you don't have graphics drivers, you can't run Vulkan or OpenGL. Windows washes their hands of any responsibility. You can at least run DirectX with software rendering regardless of hardware support. It is also for this reason that the locked-down Xbox where Microsoft can assert more control has zero tolerance for OpenGL or Vulkan.
> "Vulkan is not an industry standard" I mean yeah, in the same way Microsoft word is not an standard.
Microsoft Word, and the DOCX format by extension, has >90% market share. Vulkan has almost no presence on consoles, presence on less than half of smartphones in use, and mixed presence on Desktop because MacOS doesn't have it. Word is more of a standard than Vulkan.
> "except Switch, but it is so slow" again that seems to be a lie, doom eternal orks way, way better on it than it would be on similar software on a different API.
DOOM Eternal is one of the few games that uses Vulkan. >90% of Switch games do not use Vulkan, and found it preferable to use the proprietary API. That developers would overwhelmingly opt not to use Vulkan on Switch tells you all you need to know about the state of it. If adding another graphics API (such as Metal) was such a big deal, why in the world would they do it if Vulkan was cross-platform and worked fine? It doesn't work as well as it needs to - and adding another graphics API isn't as much of a blocker as we like to think.
DirectX with software rendering doesn't actually result in games actually being playable, unless they are 2d games that barely touch the GPU to begin with. So the software rendering fallback is completely irrelevant here, and what matters is what APIs will work when you do have the GPU drivers correctly installed. And at that point, it doesn't matter what degree of support Microsoft provides for Vulkan, only the degree to which the GPU vendor provides that support. (And the software rendering fallback actually makes it less straightforward to diagnose why a game isn't running as expected, in the case of GPU drivers not being installed. Plus, what game developer cares about the software rendering fallback enough to even test their game against it?)
So no, it's not completely honest. It's a disingenuous red herring.