The graphics API isn't that big a deal anymore. It's often a pretty small part of the engine codebase. Many games, especially those built on the popular engines like Unity, support both DirectX and Vulkan (and Sony's API too).
It is a lot bigger deal than you think, including for those very engine developers who work on Unity and etc. Having to deal with all extra lock-in APIs doesn't come for free. It takes time, resources and slows down releasing features to their users.
Vulkan _is_ a lock-in API, locking you into Google platforms; the one commercially viable platform using it is [recent versions of] Google's Android with another one on the horizon - Google Stadia. It's not necessary on Windows, not available on two of the three consoles, and not available without a wrapper on iOS and OSX.
(Technically, it is also available on Nintendo Switch, but there's also an arguably better alternative there.)
What? Vulkan is cross platform, not limited to Google or anyone else. You want Vulkan on your hardware and your OS? No one is stopping you from making a driver for it, it's an open API. For example, radv was made as Vulkan driver for AMD on Linux without AMD directly involved even (with big contributions from Valve).
If MS and Sony wanted, they could have Vulkan driver for Xbox and PlayStation tomorrow, since they are all using AMD GPUs. And no one stopped Apple from supporting Vulkan on their systems either. They don't, since they are also lock-in jerks, which is exactly the point I was making above.
That's just plain incorrect. There are already mainstream AAA titles targeting Vulkan published for Windows and macOS (via MoltenVK). Doom Eternal will only target Vulkan on PC
: https://en.wikipedia.org/wiki/Id_Tech_7
And OpenGL and Metal, and even the web! With a sweeping generalisation I'm going to say that a games company is either too small to care about the graphics API, or too big to care.
Tell that to graphics programmers. Imagine how much better performance you could expect from games if they could spend their time optimizing for one API, and not making compromises to target a half dozen.
> Imagine how much better performance you could expect from games if they could spend their time optimizing for one API, and not making compromises to target a half dozen.
That is not really an accurate statement. Graphics performance is heavily dependent on the actual hardware design of the underlying platform. You can't wave a magic API-wand and have your executable or shader be magically fast on every hardware platform.
It also depends on design of the engine, which can be improved, instead of spending time on supporting a lot of redundant APIs. Support for lock-in is essentially a tax put on developers, and it's exactly the way lock-in proponents want it.
Why couldn't it, you dont think software updates can improve performance across the board? But his point was developers could focus on a single api rather than having to deal with quirks in directx, opengl, vulkan, webgl, etc.
>But his point was developers could focus on a single api rather than having to deal with quirks in directx, opengl, vulkan, webgl, etc.
That is really an imagined scenario. An extremely tiny minority of games are targeted for such a wide variety of platforms. Real-time high-performance code is always tightly coupled with the hardware - if you want to squeeze performance out of hardware, you want to minimize abstractions to such a level as they don't hurt your productivity. If you're targeting consoles, you can maybe target the PC platform. But there is no way you're targeting the nintendo DS or a smartphone with the same codebase without major modifications to the graphics code.
> An extremely tiny minority of games are targeted for such a wide variety of platforms.
On the contrary, most games are targeted for most platforms, to increase reach and sales as result of it. Only some exclusives of console makers are not doing that, and those are clearly outliers.
> Real-time high-performance code is always tightly coupled with the hardware
That's not common at all. Unless you want to beat modern compilers with assembly code, you only will produce something worse. Sure, there are are rare cases when using hardware specific features yields extra performance. Codec developers do that for example. But for games? Not usually needed. Shaders are provided in cross platform fashion (such as SPIR-V) and that's compiled into GPU machine code by the driver. And actual game code is commonly using some high level systems language (C++, etc.) + a scripting one.
Good performance is achieved by parallelizing the engine properly, since modern hardware is increasingly multicore.
