The final blow for real gaming on the Mac, or the beginning of a new era?

[leman]

Well I'm not sure. iOS is full of pay to win kinda of games already, and nobody is really offering a true AAA title games nowadays. Intel Mac has been with us for almost 20 years, but we still don't see that many mac games (much better than PPC era, but still). So I'm skeptical. Is Mac with Arm really an attractive market segment for developer? I doubt it.

They are easier to develop for, since they offer a unified capability model and good set of tools. Intel Macs (especially with OpenGL) were pretty much terrible for game development due to idiosyncratic driver behaviors. ARM Macs will change the situation dramatically:

- considerably faster GPUs with common capabilities across the board (=faster development)
- almost console-level control over the hardware (=better performance, simplified algorithms)
- (big CON) need to use Metal

In the end, it will boil down to how popular these new Macs will be and how much interest their users will have in gaming. If the gaming performance is good and some popular games will come to Mac, it might gradually change the stigma of Apple computers as being bad for gaming.

 

[Janichsan]

Until the Apple Silicon servers do it better/faster.

Doubtful. Linux has pretty much a complete monopoly in the server/cloud computing market, on standard hardware and with open standards. Apple Silicon won't even be able to put a dent into that, no matter how good or fast it is.

 

[iindigo]

- (big CON) need to use Metal

I don't think this is actually as big of a deal as it's often made out to be. Metal is quite similar to DX12 and Vulkan, so anybody who's worked on either of the latter probably won't have much trouble with Metal. It's close enough that translation layers from DX12/Vulkan → Metal incur almost no performance hit.

Furthermore, just about every modern open source 3D graphics library and many open source emulators have very good Metal support. If community projects can manage that, gigacorps have zero excuse.

 

[Janichsan]

I don't think this is actually as big of a deal as it's often made out to be. Metal is quite similar to DX12 and Vulkan, so anybody who's worked on either of the latter probably won't have much trouble with Metal. It's close enough that translation layers from DX12/Vulkan → Metal incur almost no performance hit.

I'm not sure what gave you that idea. There are conceptual similarities between DX12/Vulkan and Metal, but that's about it. Metal is very different from the other two APIs, so that knowledge of the one does barely translate to the others and vice versa. Admittedly, Metal is actually the easier to use of these three APIs.

However, that ease of use comes with performance hit for translation layers from Vulkan/DX12 to Metal which is significant, as Metal is by far not "as close to the metal" as the other APIs.

Even without the additional overhead of the translation layer, Metal performs at best on the same level as DX11, but nowhere as well as DX12.

 

[Kostask]

I think it really depends on how fast the ARM Macs take off. I am going to assume that the initial ARM Macs will be a Macbook/Macbook Air, or at least one of them will be in the first released models. With the increased battery life, good performance, thinner size, and possibly lower price, they will be selling a ton of them to college and university students. Probably sell a lot of them to regular consumers, too.

Those college/university students will use their new ARM Macs for school related stuff, along with email, Internet (social media sites especially), and will do some gaming, mostly iDevice games. some will want to run AAA games.

The next step is very dependent on sales volume for the ARM Macs. If there is a significant increase in Mac sales after the ARM Macs come out, the ARM Macs will start to build demand for native AAA games on the ARM Mac. if, from the current ~4M Macs per quarter goes to ~10-12M ARM Macs per quarter, game developers will take notice. If the sales numbers do not increase, then the AAA gaming market will stay as it is. With 10-12M ARM Macs a quarter being sold. many to college/university students who will want to run AAA games on their ARM Macs, and with the ease of porting games to the ARM platform (including iPads, iPhones, and ATVs), game developers will take notice. Most of those college university students will NOT have the money (and in a lot of cases, the space) for a separate game console and big screen TV. Gradually, over time, ASSUMING ARM Mac sales do take off, there will be increasing demand for AAA games on ARM Macs. Ithink many game developers will notice, and some will port develop for ARM Mac (with the side benefit of being able to easily access the iDevice market as well).

 

[leman]

I don't think this is actually as big of a deal as it's often made out to be. Metal is quite similar to DX12 and Vulkan, so anybody who's worked on either of the latter probably won't have much trouble with Metal.

Metal is probably the best designed graphics API I have ever worked with — it's very compact, simple to understand, convenient to use and very powerful. But converting from DX12/Vulkan might not be as trivial as you make it sound. First of all, Apple uses a different shading language (so you need to take care about translating your shaders, either automatically or manually), and there are some big changes in how certain stuff works (for example, the tessellation pipeline setup is completely different).

Also, some of the Metal's more interesting features exploit the unique architecture of Apple's tile-based deferred renderer. Like direct control over on-chip cache, memoryless buffers, fully programmable blending. These are the things that make Apple GPUs shine as they allow one to implement some advanced rendering techniques more simply, and with better performance.

However, that ease of use comes with performance hit for translation layers from Vulkan/DX12 to Metal which is significant, as Metal is by far not "as close to the metal" as the other APIs.

That was the case for the initial Metal (it was basically DX11 with user-friendly interface), but Metal 2 and later... I mean, you can implement more or less arbitrary data structures on the GPU with pointer chasing and everything. And you can use the GPU to generate and submit complex draw calls (there was this neat demo in 2019 WWDC where they generate an entire landscape on the GPU, with instanced trees and everything, just from a height field). Programmable MSAA, efficient sparse textures, fine-grained resource locking, manual memory management (with aliasing), rasterization order, GPU SIMD lane access (what Vulkan calls subgroups), multi-GPU synchronization, ray tracing, you name it. Also, I am not sure whether DX12 or Vulkan allow you to bind resources directly from the shaders (didn't find any info) — with Metal this is possible (resource bindings are just pointers that can be freely manipulated). Plus, this year they are adding function pointers to shaders.

In a nutshell, modern Metal is indeed very close to metal, and it is especially close to Apple GPU metal, as it allows you to directly control the fast on-chip tile cache. And it does all that with a compact and user-friendly API (looking at you Vulkan). It can also do some hand-holding like memory management or resource tracking, but if you don't want the overhead, you are welcome to turn it off and take care of all the low-level stuff yourself.

 

[Jorbanead]

We are entering uncharted territory. It doesn't matter what Apple has done in the past. Apple could, in one year, completely change the rhetoric of "Apple doesn't care about AAA games" by releasing a bunch of Mac's with powerful custom GPU's and work with top AAA devs to port games like GTA or CoD over.

The three things that have me really hopeful:
1) There was a rumor about a possible gaming Mac
2) They stressed console gaming performance at WWDC (Under Rosetta)
3) iPad Pro graphics in a MacBook Air (If more people can play your game, there's more incentive)

Again, were in uncharted territory. So any rhetoric about Apple and gaming doesn't mean much to me until we see how these new Macs perform.

 

[GumaRodak]

The future of gaming is geforce now. Cloud computing and gaming. Sooner or later you will be able to play any game on the mac, even on the mb air

 

[macsplusmacs]

" geforce now. Cloud computing"

Eventually. but on my fast connection on my fast mac, it managed to both suck and blow.

I really wanted it to work, but blahh. it was horrible for me.

 

[iindigo]

Cloud gaming might catch on in countries with ubiquitous, affordable, low latency fiber connections, but I don't see it being viable for the majority of the US for at least another decade.

 

[GumaRodak]

I said sooner or later i am in ***** country and was quite ok, have double nat, that may affect it too...

 

[psingh01]

instead of getting pc games ported long after release, the mac will get ios games ported much closer to release.

 

[throAU]

As the new transition of Intel to Apple Silicon just initiated, don’t game developers think enough is enough?

The PC has seen direct 2d hardware, software 3d rendering, openGL, miniGL, Glide, Direct3d, Vulkan, x86-x64, DOS x86 segmented memory to DOS 32 bit protected mode/flat memory extender, EMS memory, XMS memory, DOS to Windows 9x, Windows 9x to NT based kernels, etc.

Isn't enough enough?

/s


People aren't writing games direct to hardware these days. They're using high level languages and game engines. The engine gets ported (unity already is, no doubt unreal engine will be as well if not already), the dev just writes against the engine.

The bigger problem is that ARM will lose WINE support; a lot of macOS games are just quick dirty WINE wrappers and that won't work any more.

 

[leman]

The bigger problem is that ARM will lose WINE support; a lot of macOS games are just quick dirty WINE wrappers and that won't work any more.

I think that WINE wrappers will be straightforward since they will just run under Rosetta. The biggest issue for existing gaming is the loss of Bootcamp.

 

[A_Flying_Panda]

On the gamer spectrum, there are 2 types people. The one on the e-sports side of the spectrum, who plays competitive games, they never looked at mac anyway.
On the casual side, i think this is really good for them. there are TONS of casual games on ipad ready to be moved to mac platform. Another raising option is cloud Gaming. Services like geforce now, google stadia, shadow are getting closer and closer to local gaming. For non-competitive games, like role play game, flight simulation, even some shooter (CoD campaign mode), i’d say some service are actually playable, i dont even notice any difference from my local machine.

 

[jerwin]

People ported Witcher 3 (and Doom 2016) to the Switch for example. Those games would easily fit far more easily on the iPad due to its larger storage, memory, cpu/gpu power, etc.

Have you seen the minimum specs for Doom Eternal?

 

[Janichsan]

instead of getting pc games ported long after release, the mac will get ios games ported much closer to release.

Is that supposed to be something to look forward to?

...a lot of macOS games are just quick dirty WINE wrappers...

Not commercial games.

I think that WINE wrappers will be straightforward since they will just run under Rosetta.

Nope.

Wine only recreates Windows' APIs. To run x86/x64 (experimentally) applications, it requires an x86/x64 CPU. As Rosetta is not an emulator, but a binary translator, Wine can't run Windows apps on Arm CPUs.

 

[leman]

Wine only recreates Windows' APIs. To run x86/x64 (experimentally) applications, it requires an x86/x64 CPU. As Rosetta is not an emulator, but a binary translator, Wine can't run Windows apps on Arm CPUs.

I don't understand why not. From the OS standpoint, WINE is just a regular x86-84 Mac application that loads some other x86-64 executable code on runtime. This is a supported use case under Rosetta.

 

[SocialKonstruct]

I am going to say that at this point unless World of Warcraft and Steam get ported to the ARM Macs then there really isn't a future for Mac gaming at this point.

 

[Janichsan]

I don't understand why not. From the OS standpoint, WINE is just a regular x86-84 Mac application that loads some other x86-64 executable code on runtime. This is a supported use case under Rosetta.

You are forgetting the Windows application. Wine only provides an environment in which the original binary is executed natively on the CPU.

Rosetta (a) won't even be able to see the Windows application (as it is "hidden" for it behind the wine executable), (b) probably can only translate Mac binaries, as it (c) requires a specific binary format, which Windows apps don't have.

 

[leman]

You are forgetting the Windows application. Wine only provides an environment in which the original binary is executed natively on the CPU.

Rosetta (a) won't even be able to see the Windows application (as it is "hidden" for it behind the wine executable), (b) probably can only translate Mac binaries, as it (c) requires a specific binary format, which Windows apps don't have.

All of this doesn't matter. MacOS also doesn't see the Windows application either, and yet it runs under WINE. What WINE does is dynamically load the windows application code at runtime and run it natively, providing Windows API hooks. This is not different from what any JIT compiler (Java/web browsers) is doing. Rosetta 2 is already confirmed to translate dynamically loaded code on demand. It doesn't need any specific binary format, it just translates any x86-84 code that you attempt to execute. You are confusing the ahead-of-time compilation and the on-demand compilation. Rosetta 2 can do both. There will just be some initial lag when starting WINE, since the code will have to be translated each time from scratch.

 

[Janichsan]

All of this doesn't matter. MacOS also doesn't see the Windows application either, and yet it runs under WINE. What WINE does is dynamically load the windows application code at runtime and run it natively, providing Windows API hooks. This is not different from what any JIT compiler (Java/web browsers) is doing.

No, it is actually very different. Wine does not compile anything or picks the code of the Windows application apart. It sits outside the Windows application, which is executed natively on the hardware, waiting for that application to make external API calls to Windows libraries, and catches and redirects these.

Wine is a virtualisation. And Rosetta 2 is confirmed not to work with virtualisation.

The only thing Rosetta 2 can translate is the code of Wine itself, not of the Windows applications it runs.

 

[leman]

No, it is actually very different. Wine does not compile anything or picks the code of the Windows application apart. It sits outside the Windows application, which is executed natively on the hardware, waiting for that application to make external API calls to Windows libraries, and catches and redirects these.

Wine is a virtualisation. And Rosetta 2 is confirmed not to work with virtualisation.

The only thing Rosetta 2 can translate is the code of Wine itself, not of the Windows applications it runs.

WINE is not virtualization, it does not use any virtualization features. WINE loads the windows executable, links the requested Windows API points to its own implementation and then just jumps into the app code. This is all in WINE docs.

From the OS standpoint, it is just a native macOS app that loads some code dynamically. It will most definitively work with Rosetta.

 

[The Phazer]

I think those of us who have struggled along gaming on the Mac using bootcamp have just lost our patience really.

This is the end of gaming on the Mac, and the end of me using a Mac.

 

[Waragainstsleep]

Doubtful. Linux has pretty much a complete monopoly in the server/cloud computing market, on standard hardware and with open standards. Apple Silicon won't even be able to put a dent into that, no matter how good or fast it is.

You're not looking at the big picture. Linux has a monopoly because it is lightweight, versatile, robust and therefore runs faster on standard x86 hardware with substantial savings available compared to Windows Server license fees and CALs.

If Apple Silicon ends up with enough extra horsepower and the software options to do the job they need, it will gain market share in that space. This would be substantially easier if it were possible to run some version of Linux natively like you could with any Macs up until now but it seems that Apple is unlikely to go this route. They could however choose to bring back Mac OS Server as something closer to current enterprise Linux offerings. I doubt they will but you never know.
A big part of why the server space might want to move to these new Macs is performance per watt. In data centres, this stat is massively important and Apple already has an advantage here that could be making data centre folks raise an eyebrow in their direction.
The other key part is Apple's custom modules. Apple can offer modules for Machine Learning, Audio processing, video work, they showed off a slide with tons of options at WWDC. If their architecture is flexibly modular enough and if the market requires it, they can bolt on all sorts of extra cores and modules to cover all sorts of specialty markets. Maybe even specialty customers.
Intel and AMD make generalised CPUs. Apple doesn't have to do that now. If they want to get into the data centre space or any other market, they can build SoCs (and entire computers) with lots of CPU cores, GPU cores, ML modules, throughput, storage options, whatever they think will be useful in that space, all running at lower power than Xeons.