Mac New Game Porting Toolkit is Wine

[dada_dave]

Arstechnica

Game Porting Toolkit is sorta like Proton for Macs?

So... I just watched the WWDC session "Bring your game to Mac, Part 1" and I gotta say, the Game Porting Toolkit sounds a lot like it could be the beginning of something like Proton for Macs. Andrew Tsai on YouTube is the one who really got me thinking about this: View...

arstechnica.com

I read through it … interesting. I only see one post after his most recent one. I don’t have an account there but it’ll be interesting to see how the conversation evolves.

 

[Jimmyjames]

I read through it … interesting. I only see one post after his most recent one. I don’t have an account there but it’ll be interesting to see how the conversation evolves.

Yeah it’s the last post I was referring to. In general that forum has a fair amount of pessimism.

 

[mr_roboto]

Another post from my favourite Mac game dev.

AFAICT, the Game Porting Toolkit seems to exist to say "See, Metal is good enough and the features can be made to work -- now go do it yourself and make some $$!"

I mean, he's not wrong about this. This is literally what Apple has to say about how they intend the Game Porting Toolkit to be used, on the page you download it from:

"Use the game porting toolkit to eliminate months of up-front work and evaluate how well your game could run on the Mac before writing any code."

Note the could run. From watching the WWDC session about it, you're supposed to use the GPT to identify where your existing renderer has performance problems on Metal / Apple GPUs. You can then estimate how much performance you should be able to gain in a real port, and how much time (and therefore money) it will cost. Finally, you decide whether the economics work - will you make enough money off the port to go ahead.

I’m pretty sure you are correct and the shader converter can be shipped, unless he means something else?

D3DMetal, the library Apple provides to translate D3D APIs to Metal, is licensed only for evaluation and non-commercial purposes. If you're a game company, this means you can't just generate a Wine bottled version of your x86 Windows game binary and sell it to end users.

The shader converter is shippable because it's the piece which is useful outside of Wine in a port which is otherwise 100% Mac native. The runtime performance overhead of binary-translated shaders should be small, and some companies will want to re-use the same DXIL shaders on all platforms as it should simplify things for them quite a bit.

(if you don't understand the distinction between D3D and shaders here, let me know and I'll try to explain, inexpertly)

I agree that he’s unspecific. Someone said he means actual hardware. He wants apple to give indie devs Mac hardware. Thing is, Apple wants big games, and they already have hardware. It’s always something with critics. I just finished hearing how Apple's efforts were no good because all these games are old, and now the efforts are no good because they aren’t providing help to port…old games.

For better or worse, it's the accepted norm for Nvidia, AMD, and Intel to spend lots of money assisting game studios, both directly (software engineer time) and indirectly (packing GPU drivers full of optimizations and bug workarounds for specific games). Apple has traditionally seen this as beneath them, seemingly due to a combination of indifference, feeling like they shouldn't do such things, and their execs just not understanding the messy reality of how the gaming industry works.

I think Brad Oliver makes a very legitimate point, tbh. You can't ship games with the GPT, and it's not just the licensing - as things stand, in many cases it's not even capable of providing acceptable performance for an official port. At best, the reason to be hopeful is that maybe there are lots of Mac-friendly devs inside game companies who want to sell their management on supporting Mac, and can now use the GPT to quickly throw together a demo without needing to justify weeks or months of porting effort. "Look at this, it's already at 20fps in this janky emulator, the GPU's only 10% busy, and we've used Apple's profiling tools to figure out how to fix it. Interested?"

And, you know, that's cool, but an easy path to proving technical feasibility is only one hurdle to clear. Management still has to decide whether they want to take on the extra support and distribution costs for an additional platform, the opportunity cost of spending developer time on the real port, and so forth.

That's why Brad Oliver's saying this might not make a big difference in game availability by itself, unless Apple decides to turn it into an actual Proton some time in the future. But that would require them to give up on native ports, which is a very un-Apple thing to do.

 

[Jimmyjames]

I mean, he's not wrong about this. This is literally what Apple has to say about how they intend the Game Porting Toolkit to be used, on the page you download it from:

"Use the game porting toolkit to eliminate months of up-front work and evaluate how well your game could run on the Mac before writing any code."

Sure. No arguments there. Brad’s opinion is that it’s an attempt drawn from a lack of real understanding about he games market. My understanding is that the term GPT encompasses both the D3DMetal runtime converter (proton) and the shader converter.

Note the could run. From watching the WWDC session about it, you're supposed to use the GPT to identify where your existing renderer has performance problems on Metal / Apple GPUs. You can then estimate how much performance you should be able to gain in a real port, and how much time (and therefore money) it will cost. Finally, you decide whether the economics work - will you make enough money off the port to go ahead.

Interestingly, in an earlier post on the thread I posted, Brad states that Apple should just go full proton. He denies the feasibility of a native Mac gaming market.

D3DMetal, the library Apple provides to translate D3D APIs to Metal, is licensed only for evaluation and non-commercial purposes. If you're a game company, this means you can't just generate a Wine bottled version of your x86 Windows game binary and sell it to end users.

The shader converter is shippable because it's the piece which is useful outside of Wine in a port which is otherwise 100% Mac native. The runtime performance overhead of binary-translated shaders should be small, and some companies will want to re-use the same DXIL shaders on all platforms as it should simplify things for them quite a bit.

Right. And Brad states that this at best makes a difference of about 10% and isn’t that useful because it focuses on Shader model 6, rather than 5, and is thus not very useful. His words “dicking around.."

(if you don't understand the distinction between D3D and shaders here, let me know and I'll try to explain, inexpertly)


For better or worse, it's the accepted norm for Nvidia, AMD, and Intel to spend lots of money assisting game studios, both directly (software engineer time) and indirectly (packing GPU drivers full of optimizations and bug workarounds for specific games). Apple has traditionally seen this as beneath them, seemingly due to a combination of indifference, feeling like they shouldn't do such things, and their execs just not understanding the messy reality of how the gaming industry works.

I believe Apple is currently doing this. I thought RE:V came as a result of Apple’s financial incentives. Likewise NMS.

I think Brad Oliver makes a very legitimate point, tbh. You can't ship games with the GPT, and it's not just the licensing - as things stand, in many cases it's not even capable of providing acceptable performance for an official port. At best, the reason to be hopeful is that maybe there are lots of Mac-friendly devs inside game companies who want to sell their management on supporting Mac, and can now use the GPT to quickly throw together a demo without needing to justify weeks or months of porting effort. "Look at this, it's already at 20fps in this janky emulator, the GPU's only 10% busy, and we've used Apple's profiling tools to figure out how to fix it. Interested?"

It’s quite possible that I misread it, but my understanding is that he’s not really focusing on the runtime converter as a problem (as I said, he’s openly stated that “proton" would be the path to Apple he recommends). His issue is the shader converter which he views as more or less tinkering.

And, you know, that's cool, but an easy path to proving technical feasibility is only one hurdle to clear. Management still has to decide whether they want to take on the extra support and distribution costs for an additional platform, the opportunity cost of spending developer time on the real port, and so forth.

That's why Brad Oliver's saying this might not make a big difference in game availability by itself, unless Apple decides to turn it into an actual Proton some time in the future. But that would require them to give up on native ports, which is a very un-Apple thing to do.

No one really knows. I agree that ultimately the biggest hurdle is if Mac users will buy these games. I don’t have any issue with a statement like that, and Im not sure anyone could. I do feel the content and tone of his posts have been less measured than that tbh. As someone who has interacted with him for a few years, I would summarise his view as: don’t waste time with metal, just use Vulcan or go for a proton solution. I just think that’s a bad choice if we want not only games on the Mac, but a healthy ecosystem for devs to thrive.

 

[dada_dave]

The shader converter is shippable because it's the piece which is useful outside of Wine in a port which is otherwise 100% Mac native. The runtime performance overhead of binary-translated shaders should be small, and some companies will want to re-use the same DXIL shaders on all platforms as it should simplify things for them quite a bit.

(if you don't understand the distinction between D3D and shaders here, let me know and I'll try to explain, inexpertly)

I noticed him make that distinction and I wouldn’t mind an explainer.

For better or worse, it's the accepted norm for Nvidia, AMD, and Intel to spend lots of money assisting game studios, both directly (software engineer time) and indirectly (packing GPU drivers full of optimizations and bug workarounds for specific games). Apple has traditionally seen this as beneath them, seemingly due to a combination of indifference, feeling like they shouldn't do such things, and their execs just not understanding the messy reality of how the gaming industry works.

It seems to me that they are in fact starting to do this, however I’m not sure that for things like Unity games, specifically brought up in his post, that things like optimizations and bug fixing in the GPU drivers would be necessary. So clearly other software support and engineering time is what is required, but unclear what … again for the specific game type mentioned. My suspicion is that for Unity games the cost of the port itself isn’t the problem (thus even an official proton-like solution wouldn’t make a difference) … but support or even the fact that they don’t think it’s worth it if they think about it at all - not even sure if distribution onto Macs in this day and age is that much of a concern?

 

[mr_roboto]

I noticed him make that distinction and I wouldn’t mind an explainer.

The extremely short version is that D3D is a library that provides an API used from the CPU, while shader programs are code that executes on the GPU.

The necessary background here is that GPU vendors have never wanted to be tied down to a stable shader ISA. In the past it wasn't uncommon for the ISA to change somewhat radically from one GPU generation to the next. Therefore, software devs could never ship fully compiled shader binaries to end users. (Except in contexts like game consoles, where the shader ISA target is deliberately very stable for many years.) For a long time, it was customary to distribute shader source code, punting the entire job of compilation to runtime. (The compiler was/is provided by the GPU driver.)

These days it's common for developers to run the front half of a shader compiler to generate compiler IR (intermediate representation), a binary structure representing the syntax tree of the original source code modified by machine-independent optimization passes. The compiler backend - machine-specific optimization passes and machine code generation - is still deferred to runtime.

For Vulkan and D3D, the shader language of choice is usually HLSL (High-Level Shader Language), and for D3D, the IR is DXIL (DirectX Intermediate Language). Apple has their own Metal Shading Language (MSL) and Metal IR.

So, D3DMetal translates Direct3D API calls to Metal API calls, while the shader converter translates DXIL 'binaries' to Metal IR. You need both of these pieces to run a D3D game run on top of Metal.

But the shader compiler's useful in a more general way. It seems that Apple's happy with the quality of their DXIL conversion - they don't think you'd necessarily gain much by porting your shader source code to MSL and compiling that to Metal IR. So, they're not trying to insist on it, which is nice because that means game devs can develop shaders once and deploy to both Windows and Mac. Since some may want to defer shader translation to runtime, Apple provides the converter as both a standalone program and a library (libmetalirconverter), with licensing terms permitting commercial use and redistribution.

 

[exoticspice1]

I am gonna be honest. I don't ever forsee the Mac to ever get games/ports as the same speed as PC, let alone consoles. I really don't like MS involvment in the gaming industry, they buy their way in.
I already made my up mind where to grow my ecosystem for gaming/ gaming hardware and that is in Sony/Nintendo/Steam for Mac. For sure games like Final Fantasy will be PS5 exclusives for a long while and I don't see standalone games like Dragon's Dogma to come to Mac after consoles/PC.

I don't see where Apple is going with this. All the games at WWDC were OLD games, not a single upcoming 2023 AAA was announced. This itself shows Apple's commintment to 3D and I will be like this till game devs port their games to Mac at the same as PC which is VERY unlikely.

Apple has yet create a AAA game and that shows what level of interest they have.

 

[dada_dave]

The extremely short version is that D3D is a library that provides an API used from the CPU, while shader programs are code that executes on the GPU.

The necessary background here is that GPU vendors have never wanted to be tied down to a stable shader ISA. In the past it wasn't uncommon for the ISA to change somewhat radically from one GPU generation to the next. Therefore, software devs could never ship fully compiled shader binaries to end users. (Except in contexts like game consoles, where the shader ISA target is deliberately very stable for many years.) For a long time, it was customary to distribute shader source code, punting the entire job of compilation to runtime. (The compiler was/is provided by the GPU driver.)

These days it's common for developers to run the front half of a shader compiler to generate compiler IR (intermediate representation), a binary structure representing the syntax tree of the original source code modified by machine-independent optimization passes. The compiler backend - machine-specific optimization passes and machine code generation - is still deferred to runtime.

For Vulkan and D3D, the shader language of choice is usually HLSL (High-Level Shader Language), and for D3D, the IR is DXIL (DirectX Intermediate Language). Apple has their own Metal Shading Language (MSL) and Metal IR.

So, D3DMetal translates Direct3D API calls to Metal API calls, while the shader converter translates DXIL 'binaries' to Metal IR. You need both of these pieces to run a D3D game run on top of Metal.

But the shader compiler's useful in a more general way. It seems that Apple's happy with the quality of their DXIL conversion - they don't think you'd necessarily gain much by porting your shader source code to MSL and compiling that to Metal IR. So, they're not trying to insist on it, which is nice because that means game devs can develop shaders once and deploy to both Windows and Mac. Since some may want to defer shader translation to runtime, Apple provides the converter as both a standalone program and a library (libmetalirconverter), with licensing terms permitting commercial use and redistribution.

My own experience is with compute, in particular CUDA, so this makes a bit more sense now. CUDA is the API, the compute kernels written in CUDA are the equivalent of HLSL, and the intermediate is PTX. Or would CUDA just HLSL in this analogy since it is geared towards running the code on the GPU?

The original post was that not having to rewrite the shaders was like 10% of the work, the other 90% being rewriting the renderer. As someone who spends his time on that 10%, or even a fraction of that since I just do “the compute shaders”, I have to admit I have little notion of the rest of the 90%.

 

[dada_dave]

Apple has yet create a AAA game and that shows what level of interest they have.

We’re at the beginning of a process not its end.

 

[dada_dave]

Sure. No arguments there. Brad’s opinion is that it’s an attempt drawn from a lack of real understanding about he games market. My understanding is that the term GPT encompasses both the D3DMetal runtime converter (proton) and the shader converter.

Interestingly, in an earlier post on the thread I posted, Brad states that Apple should just go full proton. He denies the feasibility of a native Mac gaming market.

Right. And Brad states that this at best makes a difference of about 10% and isn’t that useful because it focuses on Shader model 6, rather than 5, and is thus not very useful. His words “dicking around.."

That kind of speaks to a failure of DX12/Vulkan more than anything else. Also kind of funny: complaints of Apple only promoting the release of old games and complaints that their porting tool only benefits games using the most recent shader models. Can’t win.

I believe Apple is currently doing this. I thought RE:V came as a result of Apple’s financial incentives. Likewise NMS.

I don’t believe Apple gave a financial incentive but did offer engineering support.

It’s quite possible that I misread it, but my understanding is that he’s not really focusing on the runtime converter as a problem (as I said, he’s openly stated that “proton" would be the path to Apple he recommends). His issue is the shader converter which he views as more or less tinkering.

No one really knows. I agree that ultimately the biggest hurdle is if Mac users will buy these games. I don’t have any issue with a statement like that, and Im not sure anyone could. I do feel the content and tone of his posts have been less measured than that tbh. As someone who has interacted with him for a few years, I would summarise his view as: don’t waste time with metal, just use Vulcan or go for a proton solution. I just think that’s a bad choice if we want not only games on the Mac, but a healthy ecosystem for devs to thrive.

I find his position funny because Vulkan isn’t really used as the primary graphics language except on Linux/Android? Theoretically Vulkan is cross platform but in practice? Nintendo and Sony have their own proprietary languages for the Switch/PS5, of course MS has DX for XBox/Windows, and Apple uses Metal for iOS and those are the biggest game platforms. iOS gaming is massive, bigger than almost all the others combined, but it’s Apple who must adopt Vulkan and give up its proprietary language because Mac gaming is anemic.

However by the same token, I’m not convinced that a proton-like initiative from Apple would kill native Mac gaming - kinda going against everybody here, including Brad. I get the reasoning but the reality is two fold: for a lot of games the porting of the game isn’t the issue like Unity games. Hell there are games with Windows and iOS versions and not Mac (eg Genshin Impact). Further the examples of translation killing native are primarily pre-internet. Developers can issue a Cider/Wine/proton port and if they see interest then port natively and upgrade their users (this has actually happened btw) - especially if timed with the release of DLC (or not if it’s a “live service” game and thus constantly making money). The market and distribution model are completely different now.

The real issue is that developers need to be convinced that there’s a market to sell to and, to be fair, when they do encounter technical difficulties in bringing their games to that market that Apple will be there to help. If going full proton helps, then fine but that doesn’t negate a push for native gaming as well since for the many titles native gaming will generally be better and users will eventually want better than “good enough”.

 

[mr_roboto]

My own experience is with compute, in particular CUDA, so this makes a bit more sense now. CUDA is the API, the compute kernels written in CUDA are the equivalent of HLSL, and the intermediate is PTX. Or would CUDA just HLSL in this analogy since it is geared towards running the code on the GPU?

The original post was that not having to rewrite the shaders was like 10% of the work, the other 90% being rewriting the renderer. As someone who spends his time on that 10%, or even a fraction of that since I just do “the compute shaders”, I have to admit I have little notion of the rest of the 90%.

My understanding is that you write CUDA compute kernels in what amounts to nearly (completely?) standard C++, right? HLSL and MSL are similar, using restricted (but also extended) C-family language dialects - MSL's based on C++14. Shaders are very much like compute kernels.

You submit all kinds of data to the GPU through D3D or Metal APIs that run exclusively on the CPU - vertices, geometry meshes, rotation and other geometric transformation matrices, textures, bump maps, whatever. There's also APIs to 'bind' resources to each other so that, for example, when rasterizing a surface, the texture sampler reads from the correct texture. (in fact, texture sampling is notable as it's the most important remaining fixed-function hardware in modern GPUs - virtually everything else has become programmable.)

So yeah, the shader programs may do all the computational work once things are running on the GPU, but all the setup necessary to get things in place before shaders start crunching numbers is CPU-side D3D or Metal API calls. In most games shaders are probably much less code, but some games do have a ton of shaders. So it's not nothing that now, teams can port their rendering engine to Metal without also being forced to port shaders to MSL.

The real issue is that developers need to be convinced that there’s a market to sell to

I think this is the real reason for both hope and pessimism. It's what Joz (or was it Ternus?) mentioned in that Talk Show interview: before Apple Silicon, only very expensive Macs had GPUs good enough for demanding games, and now even the most affordable Macs do.

The pessimism is because Apple has to do a lot of convincing. The Mac has been a bad platform to target for so long that there's some pretty entrenched attitudes. There's also a major recent breach of trust: games were hit harder by the end of 32-bit x86 support than any other Mac software category. To a lot of game devs, Apple (not just Mac, mind you, I've heard bitter things from iOS devs) is the platform vendor which pulls the rug on you the most. This is a bigger problem for gaming than other categories. Games are a bit like novels, movies, and other creative media in that the business model is to spend lots of labor up front creating them, then stop that and sell them essentially forever. There are exceptions, but that's the rule. Apple's habit of breaking older software interferes with collecting that long-tail revenue, and their habit of not communicating much means it's hard to plan for when you might have to spend some programmer time updating your stuff.

 

[throAU]

Hand-optimized stuff probably always will be better, especially if you have a complex pipeline that makes certain architectural assumptions. But this should be good enough

Decent performance on games that exist > optimised performance that never gets created

This is the point that some people tend to miss - there’s a big argument against wine game porting in Linux land over this as Linux faces the same issue - nobody is going to spend a heap of time and money building games specifically for Linux until the market hits critical mass. ditto for the mac. Though Apple has an ace in the hole, as per my following post below.


edit:
also, how long before this helps developers port their windows dx12 games to IPAD?

 

[throAU]

I am gonna be honest. I don't ever forsee the Mac to ever get games/ports as the same speed as PC, let alone consoles.

I think they will. Not because of the mac specifically getting there but the iOS and iPadOS market is HUGE. Add the TvOS and Vision market (consumer headset version after the Pro) and the Apple libraries for GPU acceleration will cover an absolutely MASSIVE segment of the market. Anyone ignoring that is ignoring a market of hundreds of millions (billions?) of devices.

The fact that the mac shares both hardware architecture (just bigger and more powerful than those devices) and software APIs will ensure it inherits the market share from the smaller devices as porting from those platforms will be trivial.

This is the long game Apple is playing vs. Microsoft and Google… and i’d also argue vs. Sony and nintendo. All apple would need to do is put out something like Nintendo joycons for the iPhone (or ipad) and you’ve got a device with way better performance and connectivity than the switch that you can also justify as a business expense or “essential communications device”.

 

[dada_dave]

Sorry for the delayed response

My understanding is that you write CUDA compute kernels in what amounts to nearly (completely?) standard C++, right? HLSL and MSL are similar, using restricted (but also extended) C-family language dialects - MSL's based on C++14. Shaders are very much like compute kernels.

You submit all kinds of data to the GPU through D3D or Metal APIs that run exclusively on the CPU - vertices, geometry meshes, rotation and other geometric transformation matrices, textures, bump maps, whatever. There's also APIs to 'bind' resources to each other so that, for example, when rasterizing a surface, the texture sampler reads from the correct texture. (in fact, texture sampling is notable as it's the most important remaining fixed-function hardware in modern GPUs - virtually everything else has become programmable.)

Yeah that’s very similar to CUDA, so CUDA seems to straddle both aspects.

So yeah, the shader programs may do all the computational work once things are running on the GPU, but all the setup necessary to get things in place before shaders start crunching numbers is CPU-side D3D or Metal API calls. In most games shaders are probably much less code, but some games do have a ton of shaders. So it's not nothing that now, teams can port their rendering engine to Metal without also being forced to port shaders to MSL.

I wonder then how efficient a port would be that did a CPU translation of the D3D to Metal API calls but used Apple’s IR shader translation for all the GPU processing? That seems like it would be a quick port and I wonder what performance would be like compared to full native and full CPU translation?

I think this is the real reason for both hope and pessimism. It's what Joz (or was it Ternus?) mentioned in that Talk Show interview: before Apple Silicon, only very expensive Macs had GPUs good enough for demanding games, and now even the most affordable Macs do.

The pessimism is because Apple has to do a lot of convincing. The Mac has been a bad platform to target for so long that there's some pretty entrenched attitudes. There's also a major recent breach of trust: games were hit harder by the end of 32-bit x86 support than any other Mac software category. To a lot of game devs, Apple (not just Mac, mind you, I've heard bitter things from iOS devs) is the platform vendor which pulls the rug on you the most. This is a bigger problem for gaming than other categories. Games are a bit like novels, movies, and other creative media in that the business model is to spend lots of labor up front creating them, then stop that and sell them essentially forever. There are exceptions, but that's the rule. Apple's habit of breaking older software interferes with collecting that long-tail revenue, and their habit of not communicating much means it's hard to plan for when you might have to spend some programmer time updating your stuff.

Absolutely agree. It’s a cultural problem on both ends which can be a good and bad thing with respect to change (high barriers to start with lots of opportunities to kill momentum at the beginning but big changes can happen quickly once things get moving).

 

[exoticspice1]

I think they will. Not because of the mac specifically getting there but the iOS and iPadOS market is HUGE. Add the TvOS and Vision market (consumer headset version after the Pro) and the Apple libraries for GPU acceleration will cover an absolutely MASSIVE segment of the market. Anyone ignoring that is ignoring a market of hundreds of millions (billions?) of devices.

The fact that the mac shares both hardware architecture (just bigger and more powerful than those devices) and software APIs will ensure it inherits the market share from the smaller devices as porting from those platforms will be trivial.

This is the long game Apple is playing vs. Microsoft and Google… and i’d also argue vs. Sony and nintendo. All apple would need to do is put out something like Nintendo joycons for the iPhone (or ipad) and you’ve got a device with way better performance and connectivity than the switch that you can also justify as a business expense or “essential communications device”.

One counter point is they still will ignore the Mac. Look at Genshin Impact it's on Windows, PS4/5 and iOS/iPadOS but not on the Mac. Tim Cook also personally went to congratulate them for the App Store Award and yet it's been months and still no Mac port

 

[throAU]

One counter point is they still will ignore the Mac. Look at Genshin Impact it's on Windows, PS4/5 and iOS/iPadOS but not on the Mac. Tim Cook also personally went to congratulate them for the App Store Award and yet it's been months and still no Mac port

Early days yet. The Apple silicon mark market still is nowhere near saturated, but given the mac can run a lot of iOS/iPadOS apps (even without a device specific port) i would suggest a port is virtually inevitable at some point. Just likely not a priority - yet.

 

[cbum]

This is not the end. It isn't even the beginning of the end. But it is the end of the beginning.

 

[Eric]

This is not the end. It isn't even the beginning of the end. But it is the end of the beginning.

Welcome to the site.

 

[Jimmyjames]

Holy moly. What a take.

 

[Colstan]

Holy moly. What a take.

His take is, like many long-time Mac users, overly negative concerning Apple's latest Mac gaming endeavors. Unlike Siracusa and that developer over at Feral, Andrew's opinion isn't entirely without merit. I think he's missing the overarching point by focusing on game porting kit. Apple is pushing hard to bring native games to the Mac. The Mac doesn't need every PC game available, just enough to satisfy the market. I don't know what the mix between macOS and Linux versions of CrossOver sales are, but Proton is filling that void in Linux land.

If both efforts succeed, then CrossOver for gaming purposes becomes diminished. I don't see Apple's gaming porting kit for running Windows games as a long-term death blow to CodeWeavers. It's a short-term project to attract game developers. CodeWeavers may suffer in the immediate aftermath, but Apple won't support it forever, either because their efforts to court game developers are successful, or Apple gives up on the gaming market. However, if Apple does succeed, then the need for CrossOver is going to wane over time.

Perhaps CodeWeavers can refocus on productivity applications, but they are clearly currently focused on running Windows games. Another issue to keep in mind is that Rosetta 2 isn't going to last forever, which CrossOver depends upon, and that could be another struggle. WINE has always been chasing a moving target, it's not an ideal solution, but if Apple is successful, then CrossOver may become obsolete.

On a personal note, I've tried the various WINE solutions, as well as Parallels for Windows virtualization. I've found all of those to be lacking and have never done anything more than testing with them. I'm a "go native or go home" user when it comes to playing computer games. I'm glad that multiple solutions such as these exist, others clearly find them useful for gaming, but they are subpar experiences, in my experience.