Hacker News Reader

Comment by kitsunesoba | Hacker News Reader

I’m not sure about DX12, but my understanding is the Metal was put into production a good deal before there was even a working draft for Vulkan, which makes its existence seem more driven by an immediate need to replace OpenGL ES.

I suppose they could’ve dropped Metal right away after Vulkan became usable, but developers tend to get grouchy when APIs change out from under them that frequently.

That said there’s no reason they couldn’t support Vulkan alongside Metal, likely with one being a first-party adapter layer for the other.

View on HN

> developers tend to get grouchy when APIs change out from under them that frequently

Apple didn't care about developers when they let OpenGL rot there, so I don't think it was ever a consideration for them. Their idea for developers is "we know better than you what's good for you".

> That said there’s no reason they couldn’t support Vulkan alongside Metal

Exactly, and the real reason is - they want their API to work as lock-in rather than allow developers to have options.

Metal is also a far more usable API than Vulkan. Apple wants people to actually be able to implement things with their APIs.

Nothing (valid) stopped Apple from building such API on top of Vulkan and provide them alongside each other.

You believe that Apple should support two (three, if you count deprecated but still present OpenGL) different graphics APIs?

They have more than enough resources to support anything. Such as lower level API (Vulkan) for those who need it and higher level one built on top of it for those who need something simpler but more limited.

Do you believe Apple are somehow resource strained in not being able to do that many times over?

(disclaimer, I work at AWS)

> Do you believe Apple are somehow resource strained?

Oh if only you knew... Yes we are very engineering constrained at those companies. Money doesn't replace the fact that there isn't enough people around who have the skills and are willing to work there at any price.

And on top of that there's the opportunity costs of having them work on this instead of something else...

When MoltenVK exists as a compatible Vulkan impl on top of Metal already, it's very hard to justify this.

Opportunity cost is totally the analysis. Not just the developers, but the tech writing and support and product marketing and management oversight and continuity planning and support commitment. Building production software in a large organization is 10-50 times more expensive than a random open source hobby project. If you have a team to do that, is yet another graphics API really the best use of their time?

> there isn't enough people around who have the skills and are willing to work there at any price

I don't believe it. They could easily expand their hiring if they were sufficiently motivated. There is a combination of mismatched incentives at the team level and inefficient interviewing processes and requirements.

It's often in the interest of employees to be inefficient in this regard.

> Do you believe Apple are somehow resource strained in not being able to do that many times over?

Actually, yes.

Let's say Apple has infinite dollars, which is true enough. Therefore they can afford to hire the 100 top graphics API developers in the world and put them to work on Metal.

Now they decide they want to support Vulkan. But they can't go out and buy the 100 top graphics API developers anymore; those people are already working on Metal. They could get the next top 100 developers, but those people, as a rule, won't be quite as good as the people they already have working on Metal.

Now I guess they could mix up the teams so that every other person in the top 100 working on Metal gets folded into the Vulkan team and vice versa and have two teams of roughly equal skill working on each. But then they don't have a super-team of the top 100 devs working on one project anymore.

Now consider that Apple doesn't quite have infinite dollars, and that some top-level developers won't want to move to Cupertino or whatever else Apple may ask of them, and how do you even judge who the top 100 graphics API developers in the world are?

Maybe, even for Apple, the best approach is to get the best developers you can hope to buy and keep all their attention on one project rather than splitting it up.

All that said, yes, the ideal is that there would be some successor to OpenGL which enjoys the cross-platform support that it had. But as stated elsewhere in this thread, Metal was released years before Vulkan, so perhaps the onus for that is on those who have developed and adopted Vulkan instead of reaching out to Apple to expand Metal to other platforms (if that would have been acceptable; who knows, maybe they tried but Apple didn't allow it).

This doesn't make a lot of sense to me. May be it can take a while with training needed developers and etc. but come on, it's not some insurmountable problem. Plus Vulkan is supported for example on Windows without MS even lifting a finger.

And about your last point - Apple is really the worst candidate to ask for something to collaborate on.

OpenGL on M1 devices is just a pass through for Metal at this point - and doesn't support newer OpenGL features - so it's not really worth counting IMO. Just feels like it's there for backwards compatibility and nothing more.

Apple should ideally have supported Vulkan once it became clear that was the way the wind was blowing, and released Metal over Vulkan as a separate runtime that worked on any Vulkan card supporting their blessed feature set. It's a much nicer API, which is good for developers, and it's also in their own interests to expose a widely supported API like Vulkan if they care at all about the videogame market (which I suspect they don't): as it is, many games will just avoid Apple rather than bother to port their work to Metal, especially since Metal often has a more limited featureset than Vulkan or DX12.

This would have been a best-case scenario for everyone, basically. I'm sure many people would have been very happy to use Metal on other platforms, and in exchange Apple devices would actually have support from most modern videogames. However, that ship has probably sailed now, and WebGPU is pretty much "Metal over <X>" where X = Vulkan/Dx11/Dx12/Metal/GLES/WebGL.

I personally think it's feasible to support a Vulkan->Metal translation layer. Khronos already supports a project that does this, so Apple could take ownership of that responsibility. This would encourage developers to bring their graphics applications to Apple platforms.

The idea isn't to support multiple APIs, but to translate Vulkan into your API since it's a well-documented standard. The main issue would be API incompatibilities, which is the main place Apple could add value.

Yes, there are efforts like that already, like MoltenVK and gfx-rs portability. But they are still workarounds to Apple's refusal to cooperate. I.e. they are lock-in breaking tools.

It should have been the opposite way - Metal should have been implemented on top of Vulkan.

Reply on news.ycombinator.com