Vulkan and OpenCL will merge into a single API

One thing they did want me to make clear, though, is that this is an OpenCL decision. Vulkan's roadmap isn't changing. While I'll elaborate in the follow-up post, it's to move OpenCL more low-level and abstract (ex: as I said above, FP32 makes no sense for many DSPs or deep-learning accelerators).

On the other hand with Vulkan Nvidia or someone else would have to do some other process (I'm assuming it has some sort of extension support the way OpenGL did) and it would only get standardized later, if at all.

Or maybe it's not a new feature that gets exposed to developers. Maybe it's something along the lines of because Apple knows how the chips work and the shading pipeline and all that other stuff they are able to get extra information out of it to help reduce power draw where if they were using someone else's API it wouldn't be nearly as easy to glean information necessary.

> This decision may or may not be a conscious effort to create lock-in, but whether malicious or not, it hurts developers like me who have to develop modern cross-platform graphics applications.

My read on thing is that Apple doesn't really try to CREATE lock-in anymore, they just do what's best for Apple and that is often a side effect.

It seems like a lot of cross platform stuff has gone to using intermediate frameworks (at least in gaming) so I guess they're just sort of counting on that to bridge the gap. Outside of that (professional things) I'm guessing they think they either have enough market that they can get people to follow (possibly with some help from Apple) or they just don't think it's important enough to bother with.

The way Apple has been letting professionals just sort of sit there hoping for updates for a couple of years has been well documented, that may be the case here too. But like I said earlier, it's not like they ever had very good OpenGL support either. Are they treating a bad implementation of an old API for a good implementation of their own? Assuming they don't want to make a good implementation of the standard API (because obviously they don't) is that a good trade off? I don't know enough to make any reasonable guess.

I'm a developer and I get paid to write hardware accelerated renderers and for the past two years I've been recommending Vulkan.. I'm exclusively using Linux these days for software development. Sometimes it's not about what you're targeting for deployment but the capabilities of the development machine. For example, I do like Xcode, but I can't use it for Vulkan development, even if my ultimate platform isn't macOS/Apple.

Apple dropped the ball on Vulkan and I do hope they support it eventually.

> Having an abstraction layer over all graphics API is a minor inconvenience that can be easily done in one month.

Quite false. Take a look how long it takes major engines (like Unreal) to implement such abstraction. And how long it takes them to iron out bugs caused by underlying differences. And then try to claim it's a good thing they need to waste all this time. I don't really understand why you personally like this mess.