Definitely not. It's just funny to see the Open Source contributions reduced to "baby steps" because Apple had to play catch-up with their graphics API.
It's all good stuff, though. One of the big reasons I switched to Linux was how smooth the DirectX translation is. If Apple makes an effort to support a back catalog of DX9 titles and fairly decent DX12 coverage, that's enough to put them back on the map for me.
Since they use their own Direct3D on top of Metal (D3DMetal), you can immediately start investigating performance while not much of the game is ported yet. Even while running the game in Wine, you can already analyze graphics performance with Instruments.app.
At least this was the messaging in their talk about this: first you had to work months on a port to see how well a game would work on Mac hardware, now you can immediately run it, investigate bottlenecks and see where a port would land performance-wise before putting in any of the work.
I wonder if they will make the D3DMetal usable from native code as well, I can imagine that would make porting much easier:
- First you run on Wine + D3DMetal to get idea if your game would run well enough on Apple hardware at all.
- Then you start building the game natively, still using D3DMetal, so that you don't have to immediately port the graphics stuff.
- Once you have a running game on top of D3DMetal, you start porting it over to Metal with their shader converters, etc.
There is so much more to a modern engine than just 3D graphics. Sound, input, windowing integration, high-speed disk streaming IO, networking, robust OS integration (where to store save files, etc), just compiling it. Problem is that testing most of this depends on having a working renderer to display the game. This tool allows getting something on the screen faster so you can test everything all at once instead of having a bunch of sound, networking and platform engineers waiting around for the rendering team to get their part working.
Dunno about Apple's version but with Wine you can linnk native code against winelib, allowing you to test what you have already ported before you got everything up and running.
Of course if Vulkan was a suppoted API on macOS, developers could just port to Vulkan on Windows and then implement the rest on macOS.
I think that’s true today but it could change. I imagine Apple wants to encourage developers to build native games but I could see them loosening restrictions down the road. Maybe they eventually position this tech as the Bootcamp alternative for Apple Silicon. Time will tell.
Gaming on Apple is going to depend on how well optimized the drivers and shaders for the GPU are going to be. You'll also need some serious upscaling because most Macs come with super high res screens, a GPU that won't be able to drive modern games at those resolutions and an utterly lack of graphics card support, even in the new Pro.
Another factor is that major GPU companies put efforts into rewriting some games' shaders to make them run better on their hardware. I doubt Apple is going to do that so you'll probably end up with games performing better on other platforms soon after release.
There's more to getting games to run smoothly on a platform than compatibility software. So far, the GPU has been lacking despite Apple's attempts to hype up gaming for mac. With the rate things are going, the year of gaming on Mac may be the same as the mythical year of the Linux desktop: inching ever closer but never really arriving.
There's no need to run games at those high resolutions natively. Modern games now render only stuff like UI at the monitor's native resolution while the 3D viewport is rendered at a lower resolution and then potentially upscaled using DLSS or FSR.
It's all good stuff, though. One of the big reasons I switched to Linux was how smooth the DirectX translation is. If Apple makes an effort to support a back catalog of DX9 titles and fairly decent DX12 coverage, that's enough to put them back on the map for me.