|
While Microsoft hasn't committed to supporting Vulkan first-party, every major Windows(and macOS) graphics vendor has a compliant Windows Vulkan driver which performs well, most vendors have two or three independent implementations. There are real applications being built today under the assumption that these drivers will continue to work. Also, given that Windows versions other than ten still make up more than half of the PC market, Direct3D 12 is not even an option for most PCs, but Vulkan is. So if we're being honest, it's not really "all three", but Apple vs. literally every other platform. Obviously web applications can't simply be trusted not to crash an exposed driver, but "will result in a better API for the web." is exactly the opposite of what you would expect, given the history of high-level graphics APIs. Any layer of abstraction or heuristic other than those required for security reasons, will ultimately increase the number of implementation inconsistencies, that would be objectively worse. Then consider just the shader language. It would be considerably easier and less error-prone to just support SPIR-V shader programs; but with this there will have to be even more levels of translation, even more places for things to go wrong, and a need to make completely new tooling to generate shader binaries. Furthermore, driver bugs are a given, but Vulkan makes the skills to debug and report driver bugs portable across vendors and operating systems. If I'm an ISV and users are experiencing issues on Metal on OS X on an AMD card, I don't have layers, I largely don't know where to shim the library, and even if I could figure that out, why should I have to figure it out for every system? |
Sony doesn't has official plans to ever doing it, as the PS4 APIs are better anyway.
Nintendo is only supporting Vulkan for easing bringing in titles to the Switch, because they actually have a better API called NVN that exposes all the graphics hardware features.