Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
I don't expect this to help the porting of games, except a very few, for several reasons.
- Very few games will use Vulkan
- The decision to port a game isn't much influenced by the available tools. See for instance how many games using UE4/Unity5 are not ported to Mac/Linux even though porting is much easier/efficient than using this translation layer.
- This translation layer doesn't support some basic features like tessellation.

IOW, the only games I expect to be ported are those from developers who really push the adoption of Vulcan, who have already considered porting games to the Mac, and who don't need the most advanced features. Those devs would be Valve (who haven't released a new game in years) and... that's about it. And Croteam maybe... if their games don't need tessellation.
 
  • Like
Reactions: Flint Ironstag
Learned a lot today! I was naively hoping the floodgates would open. Still, better than nothing. I suppose it's possible for a dev to write a massive MacOS hit on Metal, but what would be the point - unless Apple bankrolled them and locked in the platform.* Anyone else will just write for Vulkan, and Macs will settle for being a certain % slower than the same hardware running on Windows.

Personally, I can live with that now (if it's still fast enough). And with eGPUs, I'm betting a bunch of laptop owners can too.

*was just daydreaming about early Bungie / Halo days.
 
Learned a lot today! I was naively hoping the floodgates would open. Still, better than nothing. I suppose it's possible for a dev to write a massive MacOS hit on Metal, but what would be the point - unless Apple bankrolled them and locked in the platform.* Anyone else will just write for Vulkan, and Macs will settle for being a certain % slower than the same hardware running on Windows.

Personally, I can live with that now (if it's still fast enough). And with eGPUs, I'm betting a bunch of laptop owners can too.

*was just daydreaming about early Bungie / Halo days.

Very few games on Windows use Vulkan. Most are using DX11 or DX12.
If the game is using one of the major engines (Unreal, or Unity) then the engine already has metal support built in.

The benefit of Vulkan on mac will be mainly simple indie games with their own engines.
 
This is also going to be a tactical decision by Valve to allow them to - going forward - spend the least time possible on a platform which probably amounts to a tiny portion of their revenue. Like with everything Valve does, they get to look like the good guys by doing something which wasn't directly motivated by what's best for their customers.
 
  • Like
Reactions: Flint Ironstag
@wubsylol you're probably right. As long as it runs "fast enough" for casuals, 99% of the market will be happy. If you're a professional (or just want the very best), you go with Windows.

Let's put it this way: If I can play Elite Dangerous in VR, natively on mMP, with all eye candy turned on, within 15% of equivalent hardware on Windows, I'll stop complaining.

/me realizes ED is DX11 :(
 
I don't get why Apple stopped supporting OpenGL at 4.1. They should have given developers a choice – you can use Metal, Vulcan or OpenGL 4.5. Is there any logic behind this?
 
If you develop a new tech for your devices to get an edge over competitors, you don't want developers to use other tech.
 
I don't get why Apple stopped supporting OpenGL at 4.1. They should have given developers a choice – you can use Metal, Vulcan or OpenGL 4.5. Is there any logic behind this?

Apple is in complete control of Metal, and can tailor it to exactly what their hardware platforms can do (esp. iOS). Why would they bother with the designed-by-committee cross platform APIs?
 
What's wrong in using up to date industry standard API for graphics? Developers and users would only benefit from it. I'm not saying OpenGL is better. I hoped Metal will level OSX with Windows in terms of speed but it did not and made it more unfriendly and harder to develop. If this is what Apple wanted they succeed.
 
What's wrong in using up to date industry standard API for graphics? Developers and users would only benefit from it. I'm not saying OpenGL is better. I hoped Metal will level OSX with Windows in terms of speed but it did not and made it more unfriendly and harder to develop. If this is what Apple wanted they succeed.

Metal predates Vulkan by several years, and Apple must've been working on it internally for at least a year or two before it was announced. So, at the time, the choices were to keep trying to convince the OpenGL folks to design an API that matched their needs, or to just go off and do it themselves. They chose the latter. Why would they abandon the last several years worth of investment in an API that is perfectly tailored to their needs that they are in complete control over?

It's pretty clear that Apple doesn't care about desktop graphics feature parity or performance, their focus is entirely on iOS. If they wanted to make it easy for people to port their DX11 game engines to Metal, the feature set would be very different (e.g. geometry shaders, very different tessellation shader API etc). They don't care about that, and the API reflects their priorities (iOS and their iOS GPU feature set).
 
Metal predates Vulkan by several years, and Apple must've been working on it internally for at least a year or two before it was announced. So, at the time, the choices were to keep trying to convince the OpenGL folks to design an API that matched their needs, or to just go off and do it themselves. They chose the latter. Why would they abandon the last several years worth of investment in an API that is perfectly tailored to their needs that they are in complete control over?

It's hard to believe that one of the richest companies on the world can't implement both up to date OpenGL and Metal together.
 
  • Like
Reactions: Spikeosx
It's hard to believe that one of the richest companies on the world can't implement both up to date OpenGL and Metal together.

Can they? Sure. Why would they, though? What's in it for them? They are in a perfect position, from their perspective: they are in total control of a mature API that is tailored to their main focus (iOS GPU).
 
Because supporting an open standard gets developer support whereas a proprietary Apple only API is how to drive developers away.

Can you name one developer who has said they won't develop for iOS because Apple only supports Metal and not Vulkan? As I said, Apple very clearly does not care about games for macOS, if they did then Metal for macOS would look very different. At this point, all the major iOS engines (Unity, Unreal etc) have a native Metal back end, so from Apple's perspective this is basically a solved problem.

Or, to put it another way, in the pre-Metal days we did not see a huge number of developers writing code for the open standard of OpenGL. Now that Vulkan is available via an open-source translation layer on top of Metal, I would be absolutely shocked if anyone but Valve used it to port a Vulkan game engine to macOS. The only other major game engine using Vulkan natively comes from id Software, and the modern id games probably require a full implementation with geometry and real tessellation shaders as opposed to the stripped-down feature set Apple chooses to expose via Metal.
 
...
It's pretty clear that Apple doesn't care about desktop graphics feature parity or performance, their focus is entirely on iOS.

Exactly why long time Mac professional users who btw like to game sometimes on MacOS, are mad cause they feel and know that they are treated like a second hand citizens.

And should we not complain?

If I buy Ferrari, I wanna drive it like Ferrari, not like Toyota (nothing against Toyota here :) )
 
Exactly why long time Mac professional users who btw like to game sometimes on MacOS, are mad cause they feel and know that they are treated like a second hand citizens.

And should we not complain?

If I buy Ferrari, I wanna drive it like Ferrari, not like Toyota (nothing against Toyota here :) )

Trust me, I get it. I used to get really frustrated by the decisions Apple was making with respect to graphics APIs, including relative feature sets and so on. However, a few years ago I accepted the fact that Apple's priorities were different to mine, and that macOS would never be a serious gaming platform. I now run Windows 10 as my primary OS, and have access to every game I want to play (and many more). I'm no longer Apple's target demographic, despite being a long-time Mac user.

So yeah, feel free to get mad, just realize it's not going to do any good and Apple has very clearly committed to the path they are on (i.e. iOS is the only thing that matters).
 
Releasing a game on a plateform is hardly a question of API, it's a question of market share.
Consoles have proprietary APIs.
And Doom was not released on Linux (makes you wonder why ID uses Vulkan). Neither are many games using UE4 or Unity, even though they would be easy to port.
[doublepost=1520577121][/doublepost]
...and real tessellation shaders...
You mean that Metal's tessellation can't do what other APIs can?
 
Last edited:
So yeah, feel free to get mad, just realize it's not going to do any good and Apple has very clearly committed to the path they are on (i.e. iOS is the only thing that matters).

It's not just that gaming is suffering. Graphic APIs and video cards are at the core of today personal computing.
I tried to go to the dark side but just can't get used to it even if Apple make it easy with bootcamp. Mac with MacOs is still better experience and I was too long under the Steve reality distortion field :)

But anyway, until this API transition madness settle down I'm rediscovering some classics like FNV and Stalker with Wine, or replaying at max settings Aspyr COD ports with conviction that Cod 2 is still more fun than Cod ww2 :)
 
Releasing a game on a plateform is hardly a question of API, it's a question of market share.
Consoles have proprietary APIs.
And Doom was not released on Linux (makes you wonder why ID uses Vulkan). Neither are many games using UE4 or Unity, even though they would be easy to port.
[doublepost=1520577121][/doublepost]
You mean that Metal's tessellation can't do what other APIs can?

The main difference between a console API and Metal is that the console, while not a cross-platform API, exposes every feature of the underlying hardware. Metal explicitly does not, and restricts desktop GPUs to the same feature set as your cell phone. I'd have to imagine this being a pretty huge turnoff when a developer is considering porting to that platform.

Metal tessellation is just such a different API that porting a DX11 engine's tessellation over to it is pretty daunting. If I were a game developer, my response would almost certainly be to just disable tessellation for Metal (and thus suffer an all-too-common massive loss in visual quality in the macOS version). For games where tessellation cannot be disabled, then I probably would just not release that game on macOS. If Metal had the same 5-stage graphics pipeline as DX11, with hull/domain/geometry shaders in addition to the vertex/pixel shaders, then Metal tessellation would be much more interested on the desktop side of things. However, their iOS GPU doesn't work that way, so Apple is never going to expose a DX11-style pipeline.

It's not just that gaming is suffering. Graphic APIs and video cards are at the core of today personal computing.
I tried to go to the dark side but just can't get used to it even if Apple make it easy with bootcamp. Mac with MacOs is still better experience and I was too long under the Steve reality distortion field :)

But anyway, until this API transition madness settle down I'm rediscovering some classics like FNV and Stalker with Wine, or replaying at max settings Aspyr COD ports with conviction that Cod 2 is still more fun than Cod ww2 :)

eGPUs could address much of this, but again, without a comparable feature set, I find it hard to believe that a flood of modern games is going to appear on macOS as soon as Apple officially supports eGPU.
 
The main difference between a console API and Metal is that the console, while not a cross-platform API, exposes every feature of the underlying hardware. Metal explicitly does not, and restricts desktop GPUs to the same feature set as your cell phone. I'd have to imagine this being a pretty huge turnoff when a developer is considering porting to that platform.
? We have games with cutting edge graphics using Metal, games which would never run on mobile. There are also Metal features specific to macOS and desktop GPUs.
As a matter of fact, Metal 2 had a feature that Vulkan just got recently with the 1.1 update, the possibility to draw to both eyes with a single draw call in VR games.
AFAIK, Metal is a good tradeoff between performance and ease of use. I've never heard a dev complaining that Metal doesn't take advantage of the desktop hardware (well, except perhaps about the lack of geometry shaders). Metal is lower-level than OpenGL or DX11.
 
Metal tessellation is just such a different API that porting a DX11 engine's tessellation over to it is pretty daunting. If I were a game developer, my response would almost certainly be to just disable tessellation for Metal (and thus suffer an all-too-common massive loss in visual quality in the macOS version). For games where tessellation cannot be disabled, then I probably would just not release that game on macOS. If Metal had the same 5-stage graphics pipeline as DX11, with hull/domain/geometry shaders in addition to the vertex/pixel shaders, then Metal tessellation would be much more interested on the desktop side of things. However, their iOS GPU doesn't work that way, so Apple is never going to expose a DX11-style pipeline.

Feral are doing it just fine....
It's also now supported natively in UE4 and and Unity.

If a game is coming to macOS it's probably using one of the main engines, or coming from Feral. So I don't see it being a huge issue?

The compute approach is where hardware is heading anyway. The same with geometry shaders, the same things are now being done in compute shaders.
 
Feral are doing it just fine....
It's also now supported natively in UE4 and and Unity.

If a game is coming to macOS it's probably using one of the main engines, or coming from Feral. So I don't see it being a huge issue?

The compute approach is where hardware is heading anyway. The same with geometry shaders, the same things are now being done in compute shaders.

Which games from Feral use Metal tessellation?
 
Which games from Feral use Metal tessellation?

From my former colleagues at Feral I believe both ‘Deus Ex Mankind Divided’ and ‘Rise of the Tomb Raider’ use and require tessellation.

Feral are doing it just fine....
It's also now supported natively in UE4 and and Unity.

If a game is coming to macOS it's probably using one of the main engines, or coming from Feral. So I don't see it being a huge issue?

The compute approach is where hardware is heading anyway. The same with geometry shaders, the same things are now being done in compute shaders.

If you’d ever worked on a modern game engine you would know that these features are fully embedded and perform few but critical functions. They are impossible to remove from the API standards now.

UE4 uses geometry shaders for a range of volumetric effects and the workarounds for Metal have non-zero performance costs and are hacks that are intermittently a maintenance nightmare. Unfortunately we *need* to do things this way as it is the only way to leverage all the dedicated silicon on modern desktop GPUs. Compute solutions for this tend to be more complicated and less efficient unless you build a heck of a lot of infrastructure - I think only Frostbite is really at that level.

In future when we make use of the DrawIndirect, MultiDrawIndirect and ExecuteIndirect functions it will not be possible to suppprt Metal tessellation as it stands today. That’s because Apple’s approach require that the CPU allocate a separate temporary buffer for each tessellated draw call, which you just don’t when using Indirect functions as in that case the draw command data is known only to the GPU. There is no way to fix this that won’t cripple performance or result in some objects just not rendering at all or consuming many times the video memory of PC, any of which would be unacceptable.

I’ll also admit that this is a change in stance for me, the growing use of DrawIndirect/MultiDrawIndirect/ExecuteIndirect has shown me the future. They really highlight problems that I hadn’t really been thinking about before.
 
Last edited:
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.