I really hope they'll catch that train, it may be their last chance to get onto tomorrows graphics stack
Apple has an API they make that will be nice and fast and do everything they want and they can update anytime they want. And because it's the same one it's going to be used on iOS and other places it will have support and people use it. There will be tooling for it.
They tried open CL and lost, along with their approach on the Mac Pro, I don't really see them going forward with it. It seems pretty clear that CUDA is what people really want right now, that's another proprietary API.
I'm not sure what the big drive for having Vulcan on Apple platforms is other than to be on the "standard". That gives Apple some benefits but they don't seem to think it's worth it. I'm not entirely sure they're wrong, especially given that Apple can make an API that fits very well with their custom chip that they put in hundreds of millions of devices. The fact that Apple operates the whole stack lets them do some of the stuff they do faster than anyone else, using Vulcan wouldn't give them that.
There isn't anything I'm aware of that Metal can do faster than Vulkan can.
The situation is simply that Apple doesn't care, since they're invested in Metal and see no reason to switch. Developers are forced to use Metal because it's the only thing Apple supports, and Apple sees no reason to make it easier to port applications to competing platforms. 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.
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.
Around 2005 or so, Apple had one of the best implementations of OpenGL in the entire industry. Sadly, in a decade, they went from the best implementation in the industry to the worst.