Hacker News Reader

Comment by mtgx | Hacker News Reader

Why does everyone misinterpret my comment to mean that I was talking about iOS?

I know Metal was announced for iOS earlier - I was talking about the support for Mac OS X. They had no good reason to adopt it for Mac OS X at that point, if they were planning on adopting Vulkan in the near future anyway. Unless, like I said, they'd prefer to keep Metal over Vulkan, and wanted to give it a head start to see if PC game developers would start adopting it.

> If that was the plan, it's probably going to fail: The developers of Unity e.g. found Metal, DX12 and Vulkan so similar that they estimate to be able to support all three with minimal development overhead.

I'm not sure how you see that as a "failure". If they are so similar that game engine developers will keep Metal around anyway, then we'll see games be built on Metal, not Vulkan, for Mac OS X. How is that a "failure"? It would mean Metal "won".

View on HN

> They had no good reason to adopt it for Mac OS X at that point

Of course they did: it was already their API of choice on iOS, platform unification alone makes it a damn good idea to adopt it for OSX: iOS is by far their most popular gaming platform, integrating the API back to OSX makes it more likely they'd get more OSX support.

Not to mention a mid-2015 release of Metal-on-OSX means they'd probably been working on it since the Metal-on-iOS release. On top of fragmenting their platforms, waiting for Metal would have meant a year-long delay.

> Of course they did

They did have a reason, except it's nowhere good. They don't want to support Vulkan because it increases their lock-in control and puts extra tax on cross platform development. Same reason MS doesn't want to support it on Xbox. It's not a good reason, it's pretty crooked but very Apple like.

Apple isn't usually about "locking people in" but more about controlling the experience. That can lead to the same thing, where they want everyone to use their API and not someone else's, but the difference is whether they have greedy, malicious intent or not. I don't think they do. Having good intentions means they are more likely to surprise you and do something good eventually.

Still, I wouldn't hold my breath on Apple supporting Vulkan soon. Their OpenGL support is usually a few versions behind so if they do ever support Vulkan I would expect it to be late.

> Having good intentions means they are more likely to surprise you and do something good eventually.

I'll agree to that when I'll see it. I.e. if their intentions are good - they'll get behind the Vulkan effort and will add native support for it on their systems. So far they clearly stayed away from it, but surely noted all its ideas to use in their lock-in variant.

Your definition of good and mine clearly differ. As has been noted, Metal existed and shipped before Vulkan, yet you claim they are using all its ideas in their own lock in variant.

Multiple people have mentioned in this thread how engine vendors have abstracted all 3 competing technologies (Metal, DX12, "Vulkan") with minimal effort.

How is there any lock in here? How is it any different from Microsoft or any other vendor deciding to, or not, implement DX12 or Vulkan?

> Metal existed and shipped before Vulkan

As was noted, it didn't exist before Mantle and before AMD decided to open it. So Apple in fact knew about it all along. Again, you can't try to dismiss their lock-in attitude with the claim that they just needed something and had no alternatives. They simply made the lock-in choice.

> Multiple people have mentioned in this thread how engine vendors have abstracted all 3 competing technologies (Metal, DX12, "Vulkan") with minimal effort.

Indeed, since they share lot's of core ideas (all of them originate in Mantle). The question is not about why one can't abstract them, but why Apple and MS push their lock-in instead of collaborating. And you wouldn't like the answer.

>How is there any lock in here? How is it any different from Microsoft

Who said it's different? It's the same crooked practice. But I'm surprised you don't see the obvious lock-in issue here.

> As was noted, it didn't exist before Mantle and before AMD decided to open it.

I see that claim, I don't see any evidence. The first evidence of Mantle being donated to Khronos date back to early 2015, not early 2014. Mantle was not open-source or open at initial release, and wasn't even supported on all AMD hardware.

> So Apple in fact knew about it all along. Again, you can't try to dismiss their lock-in attitude with the claim that they just needed something and had no alternatives.

Wait, so Apple's proprietary API is bad because AMD's proprietary existed before it? How does that even make sense?

> They simply made the lock-in choice.

Mantle was only available for AMD hardware on Windows, Apple's first need was ARM/PowerVR on iOS…

> The question is not about why one can't abstract them, but why Apple and MS push their lock-in instead of collaborating. And you wouldn't like the answer.

You do realise your pet conspiration theories are only answers to the question "what are your pet conspiration theories" no matter how many time you hint at them, right?

> Mantle was only available for AMD hardware

Its design was generic, and both Apple and MS used it to make their lock-in variants.

> If they are so similar that game engine developers will keep Metal around anyway, then we'll see games be built on Metal, not Vulkan, for Mac OS X.

And will use Vulkan on BSD/Linux, with much less problems than you have currently.

(Complaining about a lack of open software on a proprietary operating system running on proprietary hardware is a bit silly, isn't it?)

Reply on news.ycombinator.com