New DirectX 12-to-Metal translation could bring a world of Windows games to macOS

erek

[H]F Junkie
Joined
Dec 19, 2005
Messages
10,910
Might be a game changer

“CrossOver is a software package that promises to run Windows apps and games under macOS and Linux without requiring a full virtualized (or emulated) Windows installation. Its developers announced that they were working on DirectX 12 support in late 2021, and now they have a sample screenshot of Diablo II Resurrected running on an Apple M2 chip. This early DirectX12 support will ship with CrossOver version 23 "later this summer."

The announcement is simultaneously promising and caveat-filled; getting this single game running required fixing multiple game-specific bugs in upstream software projects. Support will need to be added on a game-by-game basis, at least at first.

"Our team’s investigations concluded that there was no single magic key that unlocked DirectX 12 support on macOS," CodeWeavers project manager Meredith Johnson wrote in the blog post. "To get just Diablo II Resurrected running, we had to fix a multitude of bugs involving MoltenVK and SPIRV-Cross. We anticipate that this will be the case for other DirectX 12 games: we will need to add support on a per-title basis, and each game will likely involve multiple bugs."

In other words, don't expect Steam Deck-esque levels of compatibility with Windows games just yet. There are also still gameplay bugs even in Diablo II Resurrected, though "the fact that it’s running at all is a huge win."

API translation layers have become increasingly visible and important in recent years as competing low-level APIs with the same basic goals and features have proliferated and as older APIs have aged past the point where it makes sense to spend time maintaining and improving a native implementation. Valve's Proton compatibility layer is actually a big bundle of different technologies that translate DirectX 9, 10, 11, and 12 API calls into Vulkan ones. Intel is using Microsoft-created DirectX 9-to-12 translation to improve the performance of old games on its Arc graphics cards. The MoltenVK Vulkan-to-Metal translation layer is also used in many prominent software projects, like Google's Android emulator for developers working in macOS and the Dolphin GameCube and Wii emulator.”

1686002635843.jpeg

Source: https://arstechnica.com/gaming/2023...ould-bring-a-world-of-windows-games-to-macos/
 
Reading the Codeweavers blog post it's apparently a DirectX to Vulkan to Metal translation so who knows how it'll perform.
That doesn't sound like it'll perform well. Codeweavers are lazy about making a proper DX12 to Metal wrapper. Reading their webpage does bring some interesting facts about Metal vs other API's.

"In general, Metal does tessellation differently, and is missing geometry shaders and transform feedback. Specific to DirectX 12 and Metal, there is an issue with limits on resources. Generally, games need access to at least one million shader resource views (SRVs). Access to that many SRVs requires resource binding at the Tier 2 level. Metal only supports about 500,000 resources per argument buffer, so Tier 2 resource binding isn’t possible. Metal’s limit of half a million is sufficient for Vulkan descriptor indexing, but not for D3D12. This limitation means CrossOver Mac can't support Tier 2 binding and therefore a lot of DirectX 12 games will not run."

Sounds like Metal isn't as capable as DX12 or Vulkan which is limiting the ability to run Windows games.

Another problem is that DirectX 12 uses GPU virtual addresses (VAs) to refer to resources for several things; most significantly ray tracing. According to Vulkan, their buffer device address (BDA) extension allows for the creation of complex data structures required for ray tracing, and useful for DirectX 12 porting. However, Apple has yet to add support for VAs or BDAs, insisting that existing argument buffer support is sufficient for what games want to do. While this may be technically true, it requires game designers to make a targeted effort to run on Metal. It is difficult for translation layers (i.e., MoltenVK or VKD3D) to support BDAs/GPU VAs on top of argument buffers, because argument buffers require you to encode the buffer reference into a separate argument buffer, which makes it more comparable to a Vulkan descriptor set or a DirectX 12 descriptor heap.


Also seems Metal can't do a lot of Ray-Tracing that DX12 does. Codeweavers claims they'll have this worked out by CrossOver 23, but keep in mind that all these guys do is repackage Wine with a fancy installer. On Linux there's less reasons to deal with CrossOver compared to tools like Lutris. Codeweavers also has a lot of influence in the Wine development to the point that Valve had to fork their own version called Proton. There's a lot of not good things that went on with Codeweavers and Wine, like how they had a multi-threaded GPU feature that boosted performance a lot but was somehow still missing from the main Wine builds, but always made it into CrossOver. Or how Wine devs had no interest in Gallium Nine because it wasn't useful for Mac OSX, which if you didn't know most of the money Codeweavers receives for CrossOver comes from Mac users not Linux, so there's a bias there.
 
That doesn't sound like it'll perform well. Codeweavers are lazy about making a proper DX12 to Metal wrapper. Reading their webpage does bring some interesting facts about Metal vs other API's.

"In general, Metal does tessellation differently, and is missing geometry shaders and transform feedback. Specific to DirectX 12 and Metal, there is an issue with limits on resources. Generally, games need access to at least one million shader resource views (SRVs). Access to that many SRVs requires resource binding at the Tier 2 level. Metal only supports about 500,000 resources per argument buffer, so Tier 2 resource binding isn’t possible. Metal’s limit of half a million is sufficient for Vulkan descriptor indexing, but not for D3D12. This limitation means CrossOver Mac can't support Tier 2 binding and therefore a lot of DirectX 12 games will not run."

Sounds like Metal isn't as capable as DX12 or Vulkan which is limiting the ability to run Windows games.

Another problem is that DirectX 12 uses GPU virtual addresses (VAs) to refer to resources for several things; most significantly ray tracing. According to Vulkan, their buffer device address (BDA) extension allows for the creation of complex data structures required for ray tracing, and useful for DirectX 12 porting. However, Apple has yet to add support for VAs or BDAs, insisting that existing argument buffer support is sufficient for what games want to do. While this may be technically true, it requires game designers to make a targeted effort to run on Metal. It is difficult for translation layers (i.e., MoltenVK or VKD3D) to support BDAs/GPU VAs on top of argument buffers, because argument buffers require you to encode the buffer reference into a separate argument buffer, which makes it more comparable to a Vulkan descriptor set or a DirectX 12 descriptor heap.

Also seems Metal can't do a lot of Ray-Tracing that DX12 does. Codeweavers claims they'll have this worked out by CrossOver 23, but keep in mind that all these guys do is repackage Wine with a fancy installer. On Linux there's less reasons to deal with CrossOver compared to tools like Lutris. Codeweavers also has a lot of influence in the Wine development to the point that Valve had to fork their own version called Proton. There's a lot of not good things that went on with Codeweavers and Wine, like how they had a multi-threaded GPU feature that boosted performance a lot but was somehow still missing from the main Wine builds, but always made it into CrossOver. Or how Wine devs had no interest in Gallium Nine because it wasn't useful for Mac OSX, which if you didn't know most of the money Codeweavers receives for CrossOver comes from Mac users not Linux, so there's a bias there.
The short I’ll say is this: if this allows Mac gamers to play games that they couldn’t before this is a benefit to them and devs as they will be able to make more money.

Nothing else matters. Experience does matter to some degree yes, but ultimately you’re going from 0% or nothing to say 50% level of performance for the sake of argument. Which is an infinite level of difference.
 
Of course, Apple have released their own highly restrictive DX12 > Metal translation layer that apparently doesn't implement Vulkan at all as part of their 'porting kit' - Which apparently performs better than the Codeweavers DX12 > Vulkan > Metal translation layer.

The problem is: The licence is so restrictive that game developers cannot use the porting kit as a simple means to bring DX12 native games to new Apple silicon - The 'porting kit' is only to be used for testing and evaluation purposes, meaning there's nothing stopping end users from using it to play DX12 titles on Apple silicon, but it cannot be bundled with existing software.

Apple want to dangle the carrot in front of developers, by showing what's possible under their hardware, but they want native Metal game ports only - None of this DX12 > Metal translation business. Bend over Apple, I know where you can shove your Metal API.
 
or just build a windows/linux box and laugh and point fingers at the app-le crowd when think they've won by playing diablo II with bugs
 
If gaming is a priority on the box in question, getting a Mac anything doesn't make sense.
Define “priority”.
For a long time it’s only been dependent on whether what you’ve wanted to play had a Mac native version or not. If the only game you play is WoW and your work to game at a 70/30 ratio (or any ratio really), then a Mac may not only be fine, but be the preferred solution.

There is far greater nuance here than all the PC heads have given it for a long time. And with this change, people who are casual gamers can still do all their work and game occasionally at whatever settings and be reasonably happy. At likely the same level that people who game on SteamDecks are happy.
 
If your primary use case is gaming getting a Mac Pro doesn’t make any sense whatsoever.
Honestly, I can't think of any use case for which what Apple does can't be done perfectly acceptably for a fraction of the cost on a PC platform, other than the specific creative software Apple bought out in order to keep it Apple only (Logic Pro, Final Cut Pro, etc.)

For anything and everything that Apple hasn't restricted to only their platform through monopolistic acquisitions, I'd always use something non-Apple, 100% of the time.
 
Imagine bragging about a new mac being able to run a 23 year old pc game as it's 4th iteration releases. My thermostat can run diablo 2.
For a diablo 2 the able to run is not about power, it is running windows-X86-DX12 code on arm-metal using I imagine quite the complexity of translation.

And 90s PC games-console emulator could be the type of games that would not only run OK (new AAA would have to be run at what low-900p at 20-30-40fps over all that translation) but interesting for the target audience, if you bought a Mac you probably do not play any big games on pc, but replaying mouse-keyboard PC games of your childhood just a little bit again, maybe.
 
Define “priority”.
For a long time it’s only been dependent on whether what you’ve wanted to play had a Mac native version or not. If the only game you play is WoW and your work to game at a 70/30 ratio (or any ratio really), then a Mac may not only be fine, but be the preferred solution.

There is far greater nuance here than all the PC heads have given it for a long time. And with this change, people who are casual gamers can still do all their work and game occasionally at whatever settings and be reasonably happy. At likely the same level that people who game on SteamDecks are happy.
Fair - I see no need to ever game on the go, but I'm also not often on the go anymore either. Even when I was though, and carried a gaming laptop, I never found time to use it - I always had other things to do instead. That being said - outside of hte laptop space, I'm not really paying any attention to gaming on desktop macs (nor are they really built for it). Laptops would be nice I guess, but I wouldn't personally use it - and if gaming is something on your list of concerns, Apple hardware should be pretty low on the list (buy a steamdeck if you want gaming on the go! Or an Ally).
And yet Apple has made tools to bring gaming to their Macs. This is gonna be funny considering how many Apple fans tell people that Mac OSX isn't for gaming. Apple wants to change that.
https://www.theverge.com/2023/6/7/23752164/apple-mac-gaming-game-porting-toolkit-windows-games-macos
Sure, cause folks keep asking for it, I guess. ~shrug~. Never seen a need. I've got good desktop systems for that - my mac is for working on the go.
Honestly, I can't think of any use case for which what Apple does can't be done perfectly acceptably for a fraction of the cost on a PC platform, other than the specific creative software Apple bought out in order to keep it Apple only (Logic Pro, Final Cut Pro, etc.)

For anything and everything that Apple hasn't restricted to only their platform through monopolistic acquisitions, I'd always use something non-Apple, 100% of the time.
The main ones for me were simple - real horsepower in a small package with 6+ hours of battery. Haven't been able to find that on the PC side so far. My MBP does great at it though - minor video work, lots of xterm/ssh, and all the normal office stuff.
 
The main ones for me were simple - real horsepower in a small package with 6+ hours of battery. Haven't been able to find that on the PC side so far. My MBP does great at it though - minor video work, lots of xterm/ssh, and all the normal office stuff.

Mobile is fair. They have more effective solutions there at the moment.

I mean, my work issued Dell XPS (i7-11700H I think?) can survive for 6 hours but that is mostly with light MS Office and Outlook type of work.

That said, how often do you really have to work for 6+ hours without access to power? Is this a real need or is it more a matter of convenience, so you don't have to worry about plugging in, and if it is the latter, how much is that convenience truly worth, both from a monetary perspective, and from some of the freedoms you are giving up?

Only time I can think of where I actually need that level of battery life is on interncontinental flights, and I tend to sleep on those anyway, as I find it impossible to get work done under those cramped and noisy circumstances.
 
Mobile is fair. They have more effective solutions there at the moment.

I mean, my work issued Dell XPS (i7-11700H I think?) can survive for 6 hours but that is mostly with light MS Office and Outlook type of work.

That said, how often do you really have to work for 6+ hours without access to power? Is this a real need or is it more a matter of convenience, so you don't have to worry about plugging in, and if it is the latter, how much is that convenience truly worth, both from a monetary perspective, and from some of the freedoms you are giving up?

Only time I can think of where I actually need that level of battery life is on interncontinental flights, and I tend to sleep on those anyway, as I find it impossible to get work done under those cramped and noisy circumstances.
My older dell did fine till I had to do anything requiring horsepower - and the GPUs sucked battery like mad even doing blast or HCX decoding (Virtual Desktops), which... ugh. Plus heavy web usage (the virtual center client consumes more CPU than it should by miles).

As for battery - about 2-3 times a week. Most customer sites don't have easily accessible power when you're presenting or working (and shared rooms have 2-3 plugs for 8-10 people), and it opens up a LOT of options as to where to camp/sit when doing work out of the house (don't have to find a plug, just park anywhere). Plus any time I'm in a DC power is at a premium (most ports aren't wall plugs but NEMA C13 or C20, so you're fighting over who brought the two adapters for 3-4 people), etc. I use my car a lot as an office, and it lacks an AC adapter port too - and I've easily had days where I'm in the car for 2-3 hours sitting on my laptop on calls or working (it's my mobile office - most sales/field engineers are this way). I tend to not even bring my charger anymore - I plug in at the end of the day at home, then unplug when I leave. In a pinch I have a small USB-C one that will keep the MBP running (just not charging), but I've pulled that out once so far this year at all - the rest of the time I'm on battery. Fighting over power is something I get to totally avoid :D Before, I had to plan on at MOST one meeting in the car before I'd have to find a starbucks or something to charge - and make sure I ALWAYS brought spare C13 adapters for the DC work (especially since an install can easily take hours if something goes wrong).

And to be honest, everything I do requires an xterm, firefox, the MS office suite, and the horizon + citrix clients. Apple does all that JUST fine all day long. x86 doesn't do any of it better (or notably worse), but ARM has much better battery, and OSX on ARM is far better than windows on ARM (and sadly MS Office runs like shit on linux).
 
And to be honest, everything I do requires an xterm, firefox, the MS office suite, and the horizon + citrix clients. Apple does all that JUST fine all day long. x86 doesn't do any of it better (or notably worse)

Agree, apple does this battery life scenario better. I still think I could hit 6 hours with Office/Terminal/Webapp type of work loads with my work issued last gen XPS based on windows predictions of battery life, but I have never tried. Power outlets are plentiful. I just plug in whenever I sit down.

, but ARM has much better battery, and OSX on ARM is far better than windows on ARM

As much as I dislike OSX, I do have to agree on that.

(and sadly MS Office runs like shit on linux).

I haven't tried this in years. Back in the day it used to run perfectly well using Crossover Office, but the alst time I tried this was probably ~2008?

I've never had good experiences just using straight up Wine for stuff like that.

More recently I've just used LibreOffice. It has improved a lot over the years to the point where for my own stuff I just don't need MS Office anymore. At work, I am of course stuck with it, as I need interoperability with already created Microsoft documents, but at work I ahve a work issued laptop with Windows anyway, and it would probably be frowned upon if I tried to change that :p


I haven't used Crossover Office in so long. They have since changed names to Crossover Linux apparently, and added Mac support. Interesting.

A little pricy though. £60 per year (~$75 per year) or £414 for life ($515) for life.

It annoys me that everything has to be a subscription these days.
 
Reddit users have already got Cyberpunk 2077 up and running on an M1 MacBook Pro, alongside Diablo IV on an M1 Max MacBook Pro and Hogwarts Legacy on an M2 Max. The early results look promising despite some obvious performance limitations, but there could be potential bugs from running games on Mac this way.

https://www.theverge.com/2023/6/7/23752164/apple-mac-gaming-game-porting-toolkit-windows-games-macos
These people are using the highly proprietary and hugely restrictive Apple Porting Toolkit that translates from DX11/12 to Metal directly to play these games .
 
I assume this is in part is to try and get VR game developers to port their products over in time for the launch.

And maybe they want m3 and m4 to steal back some of the game market they threw out the window decades ago.
 
OpenGL has not been updated in years (latest release july 2017), I feel it is industrial program legacy (or others no high performance or recent affair need) by now.

Vulkan fully replaced it.
Damn I'm out of the loop. I had no idea.
 
Define “priority”.
For a long time it’s only been dependent on whether what you’ve wanted to play had a Mac native version or not. If the only game you play is WoW and your work to game at a 70/30 ratio (or any ratio really), then a Mac may not only be fine, but be the preferred solution.

There is far greater nuance here than all the PC heads have given it for a long time. And with this change, people who are casual gamers can still do all their work and game occasionally at whatever settings and be reasonably happy. At likely the same level that people who game on SteamDecks are happy.
(Finishes playing Warcraft 2). Yep. :D For most people who work on Macs and happen to want to play a few games here and there, this is will be great.
 
That doesn't sound like it'll perform well. Codeweavers are lazy about making a proper DX12 to Metal wrapper. Reading their webpage does bring some interesting facts about Metal vs other API's.

"In general, Metal does tessellation differently, and is missing geometry shaders and transform feedback. Specific to DirectX 12 and Metal, there is an issue with limits on resources. Generally, games need access to at least one million shader resource views (SRVs). Access to that many SRVs requires resource binding at the Tier 2 level. Metal only supports about 500,000 resources per argument buffer, so Tier 2 resource binding isn’t possible. Metal’s limit of half a million is sufficient for Vulkan descriptor indexing, but not for D3D12. This limitation means CrossOver Mac can't support Tier 2 binding and therefore a lot of DirectX 12 games will not run."

Sounds like Metal isn't as capable as DX12 or Vulkan which is limiting the ability to run Windows games.

Another problem is that DirectX 12 uses GPU virtual addresses (VAs) to refer to resources for several things; most significantly ray tracing. According to Vulkan, their buffer device address (BDA) extension allows for the creation of complex data structures required for ray tracing, and useful for DirectX 12 porting. However, Apple has yet to add support for VAs or BDAs, insisting that existing argument buffer support is sufficient for what games want to do. While this may be technically true, it requires game designers to make a targeted effort to run on Metal. It is difficult for translation layers (i.e., MoltenVK or VKD3D) to support BDAs/GPU VAs on top of argument buffers, because argument buffers require you to encode the buffer reference into a separate argument buffer, which makes it more comparable to a Vulkan descriptor set or a DirectX 12 descriptor heap.

Also seems Metal can't do a lot of Ray-Tracing that DX12 does. Codeweavers claims they'll have this worked out by CrossOver 23, but keep in mind that all these guys do is repackage Wine with a fancy installer. On Linux there's less reasons to deal with CrossOver compared to tools like Lutris. Codeweavers also has a lot of influence in the Wine development to the point that Valve had to fork their own version called Proton. There's a lot of not good things that went on with Codeweavers and Wine, like how they had a multi-threaded GPU feature that boosted performance a lot but was somehow still missing from the main Wine builds, but always made it into CrossOver. Or how Wine devs had no interest in Gallium Nine because it wasn't useful for Mac OSX, which if you didn't know most of the money Codeweavers receives for CrossOver comes from Mac users not Linux, so there's a bias there.
I'm not surprised. When you have a reduced feature set you have a smaller API and smaller code. It's going to run a lot faster than if you have an API that supports a greater range of features. Most if not all of Apple's performance is creating an environment that is restricted to what Apple wants, not compatibility. Smaller API / feature set also means smaller silicon. Basically all of its competitiors are far more capable. What benchmarks don't cover is that there's some things that Apple silicon just can't do.
 
And yet Apple has made tools to bring gaming to their Macs. This is gonna be funny considering how many Apple fans tell people that Mac OSX isn't for gaming. Apple wants to change that.
https://www.theverge.com/2023/6/7/23752164/apple-mac-gaming-game-porting-toolkit-windows-games-macos
Apple has been very low key in their gaming acquisitions over the past few years but it is growing steadily. At the rate they are going I would not rule out Apple launching their own studio late 2024.
“Gaming” makes up a very large part of Apple’s revenue stream, though be it indirectly through their cut from iTunes. With the upcoming forced changes to their pricing structure and forced availability of 3’rd party payment options Apples only way to guarantee the money is to be the one who made the App. There is a definite financial incentive for Apple to start publishing and trying for the next Candy Crush or Fortnight to be an in-house product.
Though would Apples attempt go better than Amazons… that’s a bigger question, I fully expect their first attempts to be a little more grounded at the least.
 
I'm not surprised. When you have a reduced feature set you have a smaller API and smaller code. It's going to run a lot faster than if you have an API that supports a greater range of features. Most if not all of Apple's performance is creating an environment that is restricted to what Apple wants, not compatibility. Smaller API / feature set also means smaller silicon. Basically all of its competitiors are far more capable. What benchmarks don't cover is that there's some things that Apple silicon just can't do.
Agreed!
Metal is very simple, Apple designed it for the iPhones and iPads, and it has come a long way but feature wise I would put it alongside DX11 and certainly not DX12 and Vulkan.

Metal has some positive notes, it is simple to work with, in my opinion, one of the easiest of the "low-level" APIs.
And what I find funniest about this is while developers were begging for a low-level API when they got it they realized how much of a pain in the ass they are and they do everything in their power to not deal with it. Almost every major publisher has purchased tool kits that do their best to make DX12, Vulkan, and GNM as close to DX11 as possible so they mostly work with a canned framework developed by somebody else so they don't have to deal with the low-level aspects they begged for. Publishers who can't afford those tools are just using canned engines like Unreal and Unity which have their own canned framework, DX12 and Vulkan gave developers everything they asked for then they have spent years trying to not deal with it. This a very classic case of "be careful what you wish for".
 
This might be the biggest news in the entire history of the tech industry though. Apple is almost adopting somebody else' standard.

Almost...
 
Back
Top