Update: C++ has been moved from OpenCL 2.1 to 2.2, being released in 2017. Title and text have been updated to reflect this. A reason why Apple released Metal might be the reason that Khronos was too slow in releasing C++ kernels into OpenCL, given the delays.
Apple Metal in one sentence: one queue for both OpenCL and OpenGL, using C++11. They now brought it to OSX. The detail they don’t tell: that’s exactly what the combination of Vulkan + OpenCL 2.1 2.2 does. Instead it is compared with OpenCL 1.x + OpenGL 4.x, which it certainly can compete with, as that combination doesn’t have C++11 kernels nor a single queue.
Apple Metal on OSX – a little too late, bringing nothing new to the stage, compared to SPIR and OpenCL
2.12.2.
The main reason why they can’t compete with the standards, is that there is an urge to create high-level languages and DSLs on top of lower-level languages. What Apple did, was to create just one and leaving out the rest. This means that languages like SYCL and C++AMP (implemented on top of SPIR-V) can’t simply run on OSX, and thus blocking new innovations. To understand why SPIR-V is so important and Apple should adopt for that road, read this article on SPIR-V.
Yet another vendor lock-in?
Now Khronos is switching its two most important APIs to the next level, there is a short-term void. This is clearly the right moment for Apple to take the risk and trying to get developers interested in their new language. If they succeed, then we get the well-known “pffff, I have no time to port it to other platforms” and there is a win for Apple’s platforms (they hope).
Apple has always wanted to have a different way of interacting with OpenCL-kernels using Grand Central Dispatch. Porting OpenCL between Linux and Windows is a breeze, but from and to OSX is not. Discussions over the past years with many people from the industry thought me one thing: Apple is like Google, Microsoft and NVidia – they don’t really want standards, but want 100% dedicated developers for their languages.
Yes, now also Apple is on the list of Me-too™ languages for OpenCL. We at StreamHPC can easily translate your code from and too Metal, but we would like it that you can put your investments in more important matters like improving the algorithms and performance.
Still OpenCL support on OSX?
Yes, but only OpenCL 1.2. A way to work around is to use SPIR-to-Metal translators and a wrapper from Vulkan to Metal – this will not make it very convenient though. The way to go, is that everybody starts asking for OpenCL 2.0 support on OSX forums. Metal is a great API, but that doesn’t change the fact it’s obstructing standardisation of likewise great, open standards. If they provide both Metal and Vulkan+OpenCL 2.1 2.2 then I am happy – then the developers have the choice.
Metal debuts in “OSX El Capitan”, which is available per today to developers, and this fall to the general public.
Related Posts
Apple’s dragging OpenCL compiler problem
... bugs. Lucky on desktops the drivers have improved a lot. Apple's buggy OpenCL compiler Now to Apple. There have always been ...
The history of the PC from 2000 – 2012
... IBM-compatible clones took over from Apple, Atari and ZX Spectrum, we just got used to that a PC is an X86 with MS Windows and Office ...
Is OpenCL coming to Apple iOS?
... No, or not yet. Apple tested Intel and AMD hardware for OSX, and not portable devices. Sorry ... rumour; I'll keep you ...
OpenCL – the battle, part I
... Brook PeakStream (acquired by Google) ATI's Close-To-Metal (abandoned, ATI acquired by AMD) nVidia's CUDA AMD's ...
C++AMP on windows is only implemented on top of directcompute and has no integration with OpenGL.
The multicoreware Linux version only supports spir not spir-v and as far as I can tell has no interop with opengl.
So we still have along way to go on all platforms, not just Apple..
Microsoft has no interest in OpenCL and little support of Opengl, its graphics card vendors that are making any of it possible.
C++AMP is not my favourite high-level language at all, but it’s known (and pushed) – that’s why I mentioned it. Multicoreware’s version is indeed different and incomplete. Maybe not a good example indeed, if you know all the problems around compatibility and such.
Here I’m more optimistic. Microsoft actually is getting interested for the datacenter, because of Altera. OpenCL is actually mentioned in some of their presentations now. They do protect their ecosphere around gaming by pushing their own APIs, but not by blocking OpenCL.
I’m a bit of a noob when it comes to all of this stuff, but from what I’m reading, you’re basically saying that Apple’s “new” Metal is still no comparison to using CUDA (and other things out there) for rendering (let’s say) in Photoshop, Premiere Pro, AutoCad, etc., correct? I ask this because I’m a hackintosh builder and every hackintosh that I’ve put together has always killed any GeekBench, Cinebench and other like kind Rendering Test Apps out there that any Apple made product (like their Mac Pros) can’t even touch (when it comes to rendering power). For example my personal build The Hackinbeast (found here):
http://www.insanelymac.com/forum/topic/277433-punknuggets-mod-the-hackinbeast/
was built in 2012 and my GeekBench score was 36,619 and the best that MacPro had (at the time) was around 25,000. I’ve known others that even reached 40,000. That was based off of an OC’d motherboard and GPU’s. In fact we didn’t OC, but rather Under Clocked the system and it performed even faster. The end result was amazing.
The main reason why I’m posting this is because we’re doing another Hackintosh build and I was concerned that Apple was going to use somewhat was going to “school” the competition, but from what I’m seeing in what you’re saying, that is not the case and I can continue with my new build. Please educate me if I’m off here.
By the way this is my new build setup:
– 1 x Asus Z10PE-D16
– 2 x E5-2640 v3’s
– 2 x EVGA 980 Ti GPUs
– 2 x Crucial DDR4-2133 64GB (4x16GB) RAM kits (128GB Total)
Thank you…
You seem to forget that OpenCL is a project started at Apple, not the Khronos Group. I’m quite interested about the real reasons for Apple to choose their own API (namely, Metal).
If seeking lock-in was the leading reason for Apple’s actions, we would have seen Metal in Mavericks (10.9) alongside iOS 7.
I did not forget, but did not want to make the article too dramatic. I neither wanted to give them too much credit as it was Nvidia and AMD who did most of the work in the beginning.
Only if they openly support Vulkan and OpenCL 2.1, I will believe Apple doesn’t want to have vendor lock-in for graphics and compute.
Well, nVidia’s and AMD’s effort from a hardware standpoint. On the software side it is LLVM/Clang that currently powers OpenCL and CUDA, and enables SPIR/SPIR-V.
You are so angry that you seem to mixed up your facts.
Vulcan does not exist. It is vaporware as defined.
Vulcan is not even in LLVM. It is just a spec and some private demos.
Vulcan was directly came into being as response to Metal.
Metal is about Obj-C API integration with rest of the Apple APIs.
and in future it will be Swift.
SPIR-V and other junk is useless to Apple
as Apple is the one writing the drivers.
because Apple tried to speed up OpenGL drivers with LLVM
for last 10 years. Metal is direct result of that and OpenCL.
Apple basically created LLVM and Clang which you can claim
to be savior of Vulcan.
You cannot even list one feature of Vulcan that Apple needs to create Apps
or API or anything else.
Sadly you cannot be reasoned with.
Chris Lattner left University of illinois in 2005.
after which all his contribution to LLVM
and all the people Apple hired from the same university.
All that work was done at behest of Apple
and the copyright is owned by it.
including llvm-gcc, clang, etc
Chris tried to give llvm to gnu as way to make changes
to gcc but after that Apple decided to freeze all work on
gcc after GPL 3.0 changes.
I’ll leave it to others to comment on this. You want to be right on Apple having the copyright, and I’m happy for you. Actually they do have one copyright: http://llvm.org/Logo.html
Thank you for your opinion. I’ll try to react to each of your statements.
– As I clearly stated, Apple is making use of the current void in Khronos’s transition period to the Vulkan and OpenCL 2.1. So yeah, Vulkan doesn’t exist, if you want to state it like that.
– I’m not angry, I’m just afraid that another big corporation slows down an important open standard. Apple is obstructing OpenCL and Vulkan by recreating its functionality in Metal. You understand that obstruction of collaborations is not a good thing for the majority?
– Soon we have a public SPIR-V frontend of LLVM. Happy Duke Nukem to you!
– Seems to be your personal opinion on Metal’s future. Google on “the future of ” and you see how opinionated this space is. We all believe we can predict Apple’s future choices. Cheers, mate!
– Apple mostly finalises the drivers that vendors bring in. I don’t know all the details here, but AMD, Inte and NVidia do hire engineers for making OSX drivers.
– LLVM was used for openGL to support Intel’s GPUs. Yes, in the end it was faster than other methods – the beauty of LLVM.
– Metal’s idea came from AMD’s Mantle, where everybody took it from. I’m sure I don’t have to explain you what the main ideas of Metal/Mantle are, because you know your way around on Wikipedia. My problem with Metal is that it doesn’t bring something new (single queue and low-level, stateless API) and therefore it simply is just a variation on Mantle and Vulkan.
– I’m leaving the LLVM-discussion out, as that’s too opinionated and will end in endless ranting. We simply disagree. Ok?
Metal, Mantle, OpenCL/GL-Compute, CUDA, DirectX, Renderscript, SPIR + Vulcan etc. – There are still more to come, not less. Big GPU vendors and the Apples, Googles, Microsofts all want to push their own GPU-technology. There may be a colsolidation but not now. That is how the industry works, tough luck – make your picks or create your standard.
No surprise there’s a shortage of developers for each of the APIs. 🙂
This reminds me of the XKCD strip on standards:
https://xkcd.com/927/
I prized new century Apple for endorsing and developing open standards and technologies – using OpenGL, developing WebKit, OpenCL. BUT eventually they got big enough to play the as*hole card.
I am not an Apple hater and I also develop sw for OSX, but I hope this will blow in their face.
And it will, because there will be no vendor drivers to enable Vulkan+OpenCL2.1+ like under Windows and Linux. In the end OSX will “feel” vastly inferior UNLESS you use 100% OSX specific code. This is like today OpenGL 2.1 being default, unless you use Cocoa code, only much much much worse.
What exactly is it that you cannot render fast enough with OpenGL 3.+ and OpenCL 1.2 ????
I’d go as far as to say, if you can’t get it done with that, you can’t get it done at all !
None of those languages are magic. They’re just High-Level-Enabling a GPU and thus crunching numbers fast. But only if you setup the code smartly. You GPU won’t necessarily become faster all of a sudden just because you are using a higher version of a Brand called Vulcan or Metal or whatever. In Fact, depending on what you do i.e. Live Render in Video – as long as you stay below 4k you can do live render with OpenGL 2 and GLSL 1.2 – and those langs. are relics.
It’s not about speed. I don’t talk about speed in my post. It’s about portable modern graphics API. FWIW OpenGL is legacy, and there is no cross-platform alternative now.
OpenGL isnt Legacy. Unless perhaps in the minds of those who believes new to be right.
OpenGL is very much alive as is OpenCL. Only problem is that most folks using both dont know their way around mid-low-level code and rely on fancy high-bloat level one liners to implement them 😉
And if “Its Not about speed” – why bother to use ANY API which was written to leverage a High Speed Workflow ?
Just do it on the CPU and you won’t have to fumble about with those APIs.
I doubt you wanna use the OpenCL/GL to print a string saying “Hello World”
Personally, I highly enjoy OpenGL/CL Shared Memory and LOVE the speed I am getting.
Did I enjoy getting to the level where I was able to utilize all this power, NO. The documentation be that OpenGL – OpenCL – Apple – Microsoft, is written by those who created the logic and thus ONLY understandable to them.
Anyone, coming up with the Logic of an API should be prohibited from maintaining the documentation.
So getting there was a 500lbs Bitch. But after pushing her off the cliff… The reward was worth the stretch…
FYI – OpenGL 3.2 or older is perfectly capable of leveraging the power of any GPU and so is OpenCL 1.1 & 1.2. You just need to know HOW to get there…
I kind of hope it is legacy now. Not because of speed or cumbersome API, but because fragmentation and messy learning and support paths. And am talking about official support (Khronos), on Mac OpenGL is as good as legacy – they will never ever prioritize writing drivers for it, which were not great in the first place, not to mentation tracking version releases.
Metal is DEAD…
That’s a fact.
I dislike it too that Apple is pushing their own API, which is not better than OpenCL.
Vulkan is the immediate future…
and you know that.