Although they created OpenCL, they lost interest in keeping it up to date long time ago.

The future of OpenCL on Apple platforms is Metal Compute and I bet there is nothing at WWDC 2017 that will contradict this.

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.

Apple have a graphics API. Microsoft have a graphics API. Sony have a graphics API. Nvidia have their own libraries and compilers and so do AMD.

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.

The software development culture on the games industry is to make use of the best way to squeeze the graphics performance of a given piece of hardware until the last drop of juice.

This is an industry that was born from rewriting their whole games for each type of gaming platform they wanted to sell games to, in Assembly. In many cases using a dumb hexdump editor connected over a serial cable.

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

Plus it is something that is only written once for a specific engine.

> 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.

Apparently from the votes I sometimes get, others also share my life experience.

For anyone with experience in graphics programming, the time to triangle is just like doing hello world or playing fizz buzz.

The last time I set my feet inside of a game studio was more than a decade ago, but it started with an S not M, and I still have contacts in the industry.

You don't need to see it, it's a simple fact. Engines like Unreal, Cry/Lumberyard, Unity and etc. aren't FOSS. Plus they are commercial products. Ask their developers if current balkanized mess helps them delivering features for game developers faster. The answer is no, it takes them much longer.

So please stop claiming that it's not a problem. It only shows that you aren't sincere.

A commercially successful multi-platform game like skyrim, use at least 4 API's (DirectX, NVN, PSGL, and DirectX), but no OpenGL or Vulkan to be seen at all.

Anvil and Frostbite have no existing opengl driven software titles. And that's perfectly fine.

EDIT: Do you think debugging vulan/opengl is free? Software houses like valve have had to make their own tooling to debug and optimise for vulkan and opengl.

They added Vulkan support for Switch, but the actual main graphics API is NVN.

https://blogs.nvidia.com/blog/2016/10/20/nintendo-switch/

I bet most professional studios not using a games engine like Unreal or Unity already, will favor NVN.

Just like they did with OpenGL ES 1.0 + Cg vs Libgcm on the PS3.

Some engines like idtech4 (mb/ma, lwo) and anvil (max) directly use the asset formats which are created by an artsists desired application, not collada or fbx.

93% of Android devices don't support Vulkan, PS, XBox, UWP don't support Vulkan and Nintendo Switch API is mainly NVN, in spite of having Vulkan support as well.

Also this is the list of "great" Vulkan games released thus far.

https://en.wikipedia.org/wiki/List_of_games_with_Vulkan_supp...

For the rest of your question, sorry NDA.

So, it means you are just speculating.