[shmerl]

Semantics drifted over time. The main input was still Mantle, no a bit of doubt about it. That documentation shows it was borrowed practically verbatim in the early form.

Vulkan also didn't keep Mantle as is in every aspect when it used it.

Point is, MS didn't need to build things from scratch. They used Mantle as the starting point, same way Khronos did.

So the question one should be asking, why MS didn't collaborate while they very well knew the collaborative API is going to happen. No one stopped them from making that collaborative API more friendly or better. But MS being MS they rushed with NIH.

[MindSpunk]

I suppose it could be seen as NIH, but there are legitimate engineering benefits for Microsoft with its own API. It's important to remember that Direct3D used to be a completely separable component from Windows, and wasn't installed by default. Around the same time D3D12 and Vulkan were happening Windows also pulled D3D in as a core system component that will be universally available.

If you're an engineer trying to pick "the" GPU API for Windows the only real argument that can be made for picking Vulkan, the open API, over the internal API Microsoft already had for ~15 years by that point is that it's the 'open source friendly' choice. How do you justify using someone else's API as a core Windows API over your own solution that you already had. There's no engineering or business justification really.

It's similarly easy to construe Vulkan and Mantle as an attempt by AMD to take control of the GPU API space and specify an API particularly friendly to their hardware as the standard. They largely even succeeded considering what Vulkan became. Even D3D12's binding model is basically an exercise in how close we can get to directly exposing AMD's "anything goes" binding model while still allowing NVidia to function. It's very nice as a GPU vendor when your driver can be made closer to a no-op than your competitors.

Too many people pile on D3D12 simply because of Microsoft, rather than fairly considering the context of what created it. Apple made the same decision too with Metal, but I rarely hear any complaints there.

[shmerl]

Engineering reasons just don't seem convincing when MS has DX only policy on Xbox and a long history of anti competitive behavior, especially in the gaming segment.

If MS would have allowed using Vulkan on Xbox for instance, I would have been more willing to give them the benefit of a doubt. But as it stands, I see them pushing DX as having lock-in motives.

[smileybarry]

> […] when MS has DX only policy on Xbox […]

PlayStation only supports Sony’s own, proprietary Gnm/Gnmx[1]. I heard their APIs are somewhat based on (very old) OpenGL, but different enough to not actually be compatible.

Nintendo Switch supporting OpenGL or Vulkan is an exception in the console space.

1: https://en.wikipedia.org/wiki/PlayStation_4_system_software#...

[MindSpunk]

Very few switch games use Vulkan on the Switch. NVN is the true native graphics API on the Switch, which is Nvidia's API. Those that have tried Vulkan on Switch usually end up ditching it for NVN as Vulkan leaves too much performance on the table on a system with little power to spare.

[shmerl]

Sure, I'm not saying Sony is any better in this regard. They copy worst ideas from each other.

[smileybarry]

Right, but my point is that this isn’t some famous malicious intentional lock-in by “evil Microsoft” — it’s how every console is designed. (And arguably Xbox has an advantage here because it shares DirectX with Windows)

There’s no evil MS lock-in here.

[shmerl]

Not really. It has nothing to do with console idea or form factor, it's just how these messed up companies are "designed" in using anti-competitive methods. See Steam Deck which uses Vulkan just fine.

There is absolutely lock-in in MS and Sony's approaches. There is no inherent need in it just becasue it's a console.

[Femtiono]

Of course they want to control the ecosystem the same as every one else.

There is a reason for NES games having a certificate from Nintendo.

And yes most developers do not care about it anyway if it's good.

[shmerl]

That's not an excuse for lock-in. But they indeed always tried to do that. ActiveX, browser wars, etc.