“Not like that”

That’s been the joke since it was released.

Just Apple one-upping the “runs on a toaster” adage.

We’ve been right on the edge of “Mac Gaming” since 2006 when they switched to Intel. Almost twenty years later and every year it’s brought up as something “right around the corner,” but during the Intel years they always had garbage GPUs.

I guess we’ll see if/when games will be a thing on Arm.

From the interview, the push is pretty clearly at encouraging developers to build games for iPhone, iPad, and Mac through one workflow, and a unified API that targets all 3 types of devices (potentially throwing in an Apple TV as well).

Self identified gamers are pretty dismissive towards non-AAA gaming on mobile devices, but those types of games do make a lot of money.

I mean, yeah, they could do exactly that. “We cater to the needs of creative professionals and personal users that need a streamlined user experience” or some other execu-speak. Who are they gonna alienate, all those gamers that are already not buying macs for gaming?

I think for people who buy pre built gaming PCs the Apple tax might be roughly equivalent… If they also have an iPhone or a MacBook already… It might not be a big jump to go to Mac gaming

deleted by creator

with the Apple tax included you’re always going to be paying a lot more for similar specs to something you can build yourself.

Don’t underestimate Apple. They are already ahead in the performance-per-watt game. Nvidia is on a dead-end street with their GPUs. They get way too hot and use too much power. Discrete GPUs are going the way of the dodo. The performance penalty is just too big, especially for GPGPU tasks. Memory limits are already an issue for AI tasks. Even an 4090 only has 24GB RAM. Contrast this with an M2 Ultra that can be specced up to 192GB, and all of that is accessible by the GPU.

which also is split between GPU and CPU

deleted by creator

If it’s true then imagine the price tags they will put on these machines to make profit.

Any chance to senselessly gouge their consumers is a good one for Apple.

The already have the best x86 emulator. They also have a lot of leverage over big game manufacturers. Especially ones that have iPhone apps. They are able to use carrot and stick to get Devs to develop for MacOs. I don’t think they will, they just don’t want to say they don’t care about gaming.

Isn’t the problem that they are using ARM hardware.

No, not at all. CPU architecture isn’t really a big issue when porting games. The real effort is in different OS en GPU APIs.

Porting a game from Windows/x86 to Linux/x86 is a lot more effort than porting from, say, Windows/x86 to Windows/ARM.

Like sure your x86 emulator can be good, but if you look at something like proton it’s taken years for it to get good. And that’s not even a different CPU architecture.

The CPU architecture is the easy part. You need to cover a couple of hundred CPU instructions that are all well documented. The difficulty that proton covers is the thousands of APIs that WIndows offers, lots of which have undocumented quirks and are much-higher level than a CPU instruction.

For example, an CPU may have an instruction to add 2 integers. Instructions like that are very well documented and relatively simple. They perform one specific operation. By contrast the API’s that Windows offers are much more complicated and do a lot more, they operate on complicated structures and there is a lot of (implicit) behavior associated with it. Take for example a simple operation like opening a file. There are a lot of subtleties in how Windows deals with files and filesystems, all hidden behind that simple API call. And games can depend on that specific behavior .

Apple already has Rosetta to run x86 code on ARM. It’s not exactly an emulator, it’s a dynamic code translator. It takes x86 code and turns it into ARM code before running an app. This is a (relatively) easy thing to do.

One major difference between ARM and x86 is the memory model. X86 guarantees that memory writes are performed in the order they appear in code (Total Store Ordering), whereas ARM uses weak memory ordering, meaning the CPU can re-arrange the order it writes things to memory if it wants to (usually for efficiency/performance reasons). On ARM if you want to be sure that a write is completed before you do something else, you have to insert a so-called memory barrier. This costs performance, but it doesn’t matter because most code doesn’t care about write order. However, since x86 code won’t have these memory barriers you don’t know which x86 code does and doesn’t depend on the write order. So in your translated x86 code you have to insert a memory barrier after each write. This is why running x86 code on ARM is traditionally slow. Apple solved this by adding a TSO-mode to their ARM processors, this is only enabled when running translated x86 code and implements the same memory model as x86 processors.

So running x86 code isn’t the big issue.

They already use the same code from Wine to implement the Win32 APIs and have their own translation layer between Direct3D and Metal (similar to DXVK).

But all this is only meant to give developers an idea of the feasibility of porting their game to Apple OSes. Developers are still expected to do a proper port.

There are a couple of reasons that Apple is now in a better position for this:

1. They now have tooling in place that helps porting existing D3D shaders to Metal, which makes the porting effort a lot easier.

2. There is now a unified architecture between iOS/iPadOS and macOS. They have similar GPUs and APIs. If you port your game to Mac you can also easily port it to iPhone and iPad, and those are a lot of potential customers.

Then there’s what could happen in the future:

All that’s needed is for Apple to release an updated Apple TV with one of their high-end processors in it and they also have what is basically a console, which would only add to the number of customers you could reach with that porting effort.

Meanwhile, on the PC side of things they are not looking good. PCs are still stuck with discrete GPUs with separate VRAM instead of integrated solutions with unified memory. IMO this is a dead end street. PC GPU’s are also inefficient, run way too hot and use too much power.

I suspect Nvidia is going to focus on the AI market, and may even get out of the desktop GPU market in time. For them to offer a compelling SoC for the PC market, that market would first have to switch to ARM, as Nvidia doesn’t have a x86 CPU themselves.

AMD is in a better position, they make great x86 CPUs and already make APUs. They need to drive this advantage and go all-in on advanced APUs

Apple meanwhile seems to be getting serious about GPUs, so it’s interesting to see what they’ll do in the future. For now they have the power per watt advantage. Apple usually has a very clear roadmap in mind and executes it at their own leisure. I expect major steps in GPU performance for the coming few generations of M-series SoCs.

Metal — it’s a proprietary graphics API made by Apple

Apple doesn’t support add-in GPUs anymore since switching to Apple silicon. Their iGPUs though are better than other iGPUs, performing in line with mid range discrete GPUs. They want the experience to be more console-like than PC-like though, you buy a standardized set of hardware and that’s that.

No, Steam works sort of fine on Macs. It’s just that there’s not many new games on Apple these days. I think even native Linux might have more games these days.

I think Apple dropped some stuff that would make it so 32 but apps wouldn’t work and a ton of games are 32 bit apps. But I’m not sure if they actually did that or just talked about it.

Valve has stopped supporting Mac on some games (cs2 afaik)

It would be extremely difficult to get an arm mac binary to run on windows. Not impossible, but much, much more engineering than bypassing DRM. You’d need reverse wine, which the Darling project could possibly be, but after years of work barely supports GUI applications.