This is not true! The International Workshop on OpenCL was held this past week in Toronto (OpenCL 2.2 was announced there), and there was a session with several Khronos project leaders (including the chair). The future of OpenCL was a big topic and they explicitly said that this has not been decided yet. Yes, it probably makes sense to merge the Vulkan and OpenCL SPIR-V flavors more, but that's not 'Vulkan anf OpenCL will merge'. If anyone reading this was at the conference too and heard something different, please chime in - but if what this article says was said there, it must have been in a parallel conference with people saying the opposite things than what I heard.
The core thing to understand is that (a bit simplified) both Vulkan and OpenCL (as of 2.2) run on SPIR-V IL. So in that context (with that common foundation for both API's in the near future - well, depending on your definition of 'near' I guess...), it makes sense that someone at Khronos might have said something about 'converging' - large parts of the ecosystem can be shared (compilers/transpilers, tools, ...), some parts of the API's might be 'aligned' more, ... But 'converging' is not 'OpenCL will be folded into the Vulkan API', which I think is an overhasty conclusion by the author of OP. If anything (at least, this was my impression from the conference), the big new things for OpenCL are on devices that are not GPU's (well, on FPGA's, to be more precise). This might require some specific support (for features) that don't have a place in Vulkan at all. That's not saying that the alluded to 'aligning' or 'converging' can't happen, but there is no One API To Rule Them All ('them' = graphics and compute).
So, to conclude: I see why the author would draw the conclusion he did, and if what he cites really are literal citations then maybe the Khronos communication could have been a bit more clear, but I don't think this conclusion is correct.
I am currently writing up another post, which is based on an interview I did with Tom Olson (Chairman of Vulkan) and Neil Trevett (President of Khronos Group) on Friday. While the implications of the announcement are smaller than I speculated (ex: the Khronos Group weren't concerned about Apple's ownership over OpenCL's trademarks and a few necessary patents) the announcement is correct.
Neil: "Congratulations. You win the prize for finding the extra press release hidden in the quote."
I'm still digesting the dense, ~40 minute discussion, but OpenCL's roadmap is to merge into Vulkan's. There's a bunch of reasons for it (ex: OpenCL pushes FP32 support onto hardware where it doesn't make sense, like DSPs and deep-learning applications) but I'll elaborate on that with the follow-up. Might take a few days though.
Thanks for following up here, and sorry that my reply is late - too late to make any difference, probably.
Yes, I was at Neil's keynote that you link the slides for. I still do not agree with your conclusions, or maybe rather with how you frame them. OpenCL is not 'being merged into Vulkan'. Rather, 'the next version(s) of OpenCL will align more ('converge') with Vulkan'. For example, you claim 'The Khronos Group are converging OpenCL and Vulkan into a single API: Vulkan.'. I do not get that from either of the Khronos 'clarifications', nor from any of the presentations given last week, nor from any of the discussions I had with people from the various Khronos workgroups, including the OpenCL-related ones.
I've asked a few other people who were there how they perceived the message but haven't heard back yet. Maybe I'm just thick, wouldn't be the first time. But for now I do feel that you're spinning a more sensational story ('OpenCL will go away and be merged into Vulkan!' - on a meta-level, it's a sad reflection on my life that I consider that 'sensational'...) than what is actually going on.
I'm still writing up the interview that I did with them (Tom Olson and Neil Trevett) on Friday, after the initial post was published, but they do intend to merge OpenCL into Vulkan.
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).
I think Apple has made it abundantly clear they don't care. They've never released terribly good or performant open GL drivers on OS X. My understanding is they've always been quite behind on features.
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.
> 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.
What I was referring to there is that since Apple makes the chips (for iOS only, for now) and Apple makes the API and Apple makes the drivers (even on the Mac side) then Apple can implement new features they come up with faster than others. For example if Apple makes a new bit of the A23 chip that is designed to do some Neville feature that's not currently in Vulkan or Metal ( to make up something stupid, something that accelerates replacing colors of an image with their square roots) Apple can put it in the shading language and the driver extremely fast. They can have it ready for announcement.
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.
Correction, that is what they have had for 20 years. Steve ignored and refused to push graphics technology and cook is doing the exact same thing. I can't count the years growing up I wanted Apple to have the latest games. This was back in the IIc days. Steve hated games. Apple never took a lead roll here. They never supported game tech. The graphic stack especially. You don't think games when you think Mac. You never have. And games are where graphic technology is pushed the hardest. I don't see this changing with Apple ever. It wasn't even a consideration with Steve and it's not with Tim either. It is what it is. Shrug.
> But like I said earlier, it's not like they ever had very good OpenGL support either.
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.
In reality, for most developers, it is a non-issue to bringup a new graphics API backend. See, for example, Arseny Kapoulkine's experience porting to Metal: http://zeuxcg.org/2016/12/01/metal-retrospective
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.
We develop server based hardware-accelerated renderers and compositors for web applications, e.g. dynamically generated product images. None of those targets are relevant. Think ImageMagick but done on hardware + 3D geometry in many cases.
Yes they do, just indies and FOSS devs on HN don't.
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.
No, they don't. Because it's not free and wastes their time. You just keep repeating this weird idea, that developers like this balkanized landscape. They don't. No one likes it, except for lock-in freaks who created it to keep cross platform development expensive.
> 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.
If you have experience, you'd know it's time consuming and taxing. You either like this time wasting, or you benefit from this taxation (working for MS?).
Only FOSS devs see it as time consuming and taxing, professional game studios see it as an opportunity to explore hardware performance to the last drop.
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.
> Only FOSS devs see it as time consuming and taxing
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.
The reality is, in house tooling and engines do use multiple graphics api's, and that's perfectly fine. They are not slapdash implementations; professional graphics rendering programmers know and use these API's (See the GPU Pro book series, and Real Time Rendering), it's their profession.
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.
And using those 4 APIs isn't free, don't you think? It means a lot of resources are spent on supporting them, instead of fixing actual bugs or developing better features. I.e. they pay the tax. This applies to in-house or third party engines all the same. And it's not perfectly fine by far.
I agree it's not free. But will you make return on the effort/time/money invested?
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.
It's a bet you would win. And not just for Graphic api's but asset API's.
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.
Great, maybe we'll finally get OpenCL support in the proprietary Nvidia driver for FreeBSD? And then maybe CUDA support in their driver also? One can hope/dream.
They had to get it out of the door at some point. The industry support they received was tremendous as it was and I imagine more waiting would have made some people there very nervous. I think it turned out well as it did.
