Mac Pro Puts the Pedal to Metal in Apple's Race with Nvidia(appleinsider.com)
appleinsider.com
Mac Pro Puts the Pedal to Metal in Apple's Race with Nvidia
https://appleinsider.com/articles/19/10/18/editorial-mac-pro-puts-the-pedal-to-metal-in-apples-race-with-nvidia
19 comments
>talent for writing thousands of words of speculation based on, say, two sentences in release notes is still going strong.
In fairness I'd love to have a piece of that
In fairness I'd love to have a piece of that
I am sure this is not the first time I heard someone describe him as "writing thousands of words of speculation based on, say, two sentences in release notes"
And DED is Apple's biggest Fanboy that barely understands tech or business and continue to fantasise Apple as a religion and Apple Park as Elysium.
And yet there is a group of people continue to follow its post. Even AI is still in my RSS feeds I cant remember when was the last time I actually clicked on any of its content.
I am even thinking if I should have flag this.
The worst part, is Horace Dediu, a well respected analyst that covers Apple, invite him to speak in one of his Apple investment conference.
And DED is Apple's biggest Fanboy that barely understands tech or business and continue to fantasise Apple as a religion and Apple Park as Elysium.
And yet there is a group of people continue to follow its post. Even AI is still in my RSS feeds I cant remember when was the last time I actually clicked on any of its content.
I am even thinking if I should have flag this.
The worst part, is Horace Dediu, a well respected analyst that covers Apple, invite him to speak in one of his Apple investment conference.
He was writing his entries at “Roughly Drafted” for years and he was a well known but not well respected blogger I think back as early as the 200x’s.
It makes sense though. I have been thinking the same for a while now. What they need for that strategy to work though is to provide cloud computing offers for Metal, and I don't see that anywhere on a meaningful scale.
A cheap Metal cloud computing offering from Apple would truly be something. Would probably make them better at writing cloud software, too ...
A cheap Metal cloud computing offering from Apple would truly be something. Would probably make them better at writing cloud software, too ...
He even gets huge amounts of the past history wrong.
Constantly describing Apple users as "affluent" bugs the hell outta me for some reason.
Metal is racing against Vulkin as well, because Apple needed to have their own standard they owned. Except Metal has zero support outside of Apple products.
Besides, what Metal represents is Apple's attempt to have yet another vector for their infamous walled garden and vendor lock-in strategies.
Further, the article and the website are intentionally and blatently biased. Quotes like this showcase their extreme bias:
> One can be righteously indignant that Apple isn't subsidizing everyone else with support for their platforms, whether CUDA, Vulkan, or even Android. But such emotions won't have any bearing on the final outcome of who wins and who loses in the market for developing and commercializing the graphics technology of the future.
The absolute derisiveness of open standards coupled with their insults against those that would showcases quite well the position of the article, its authors, and the website itself.
Besides, what Metal represents is Apple's attempt to have yet another vector for their infamous walled garden and vendor lock-in strategies.
Further, the article and the website are intentionally and blatently biased. Quotes like this showcase their extreme bias:
> One can be righteously indignant that Apple isn't subsidizing everyone else with support for their platforms, whether CUDA, Vulkan, or even Android. But such emotions won't have any bearing on the final outcome of who wins and who loses in the market for developing and commercializing the graphics technology of the future.
The absolute derisiveness of open standards coupled with their insults against those that would showcases quite well the position of the article, its authors, and the website itself.
Yes, AppleInsider is totally biased.
But the competition here is not "Open Standards", it's CUDA, which is Nvidia's own proprietary standard. There is no Open Standard which has any kind of market share.
The claim that Apple is against Open Standards is a bit misleading in this case. Apple invested a lot of money and spent years pushing Open Standards in this market in the form of OpenCL... the open standard which Nvidia refused to support and in general the industry ignored.
Apple is no angel and in many other places they've ignore standards, but in this case, there have been standards around for years and both the competition and the market have largely ignored them. Singling out Apple here is just wrong.
But the competition here is not "Open Standards", it's CUDA, which is Nvidia's own proprietary standard. There is no Open Standard which has any kind of market share.
The claim that Apple is against Open Standards is a bit misleading in this case. Apple invested a lot of money and spent years pushing Open Standards in this market in the form of OpenCL... the open standard which Nvidia refused to support and in general the industry ignored.
Apple is no angel and in many other places they've ignore standards, but in this case, there have been standards around for years and both the competition and the market have largely ignored them. Singling out Apple here is just wrong.
Isn't Vulkan the open-source specification they're ignoring in favor of their own?
Metal and Mantle were both proprietary frameworks that were in development at the same time.
AMD announced the existence of Mantle at their Developer Summit in November 2013. Apple announced Metal at WWDC the following June and shipped it that fall.
By the time AMD donated their Mantle code to Khronos to serve as the basis for Vulkan, Apple had already shipped Metal.
AMD announced the existence of Mantle at their Developer Summit in November 2013. Apple announced Metal at WWDC the following June and shipped it that fall.
By the time AMD donated their Mantle code to Khronos to serve as the basis for Vulkan, Apple had already shipped Metal.
> By the time AMD donated their Mantle code to Khronos to serve as the basis for Vulkan, Apple had already shipped Metal.
Metal v1 was so woefully incomplete, AMD was in no position to ship something similarly limited. Vulkan 1.0 is functionally similar to Metal v2, which shipped several months after Vulkan 1.0.
Metal v1 was so woefully incomplete, AMD was in no position to ship something similarly limited. Vulkan 1.0 is functionally similar to Metal v2, which shipped several months after Vulkan 1.0.
They're fighting on the CUDA-OpenCL-MSL layer.
They're not really talking about the higher level Vulkan-OpenGL-Metal stuff.
So CUDA and OpenCL are the specs being ignored by Apple.
My own opinion, everyone should probably just use OpenCL and contribute to it as necessary, but that's not gonna happen.
They're not really talking about the higher level Vulkan-OpenGL-Metal stuff.
So CUDA and OpenCL are the specs being ignored by Apple.
My own opinion, everyone should probably just use OpenCL and contribute to it as necessary, but that's not gonna happen.
Again, Apple invested huge amounts of money and effort into OpenCL with the previous generation of the Mac Pro and got very little adoption. Suggesting Apple is ignoring OpenCL is simply not true. They made a significant effort to make it work and it just didn't pan out.
That Apple hasn't invested in Vulkan is a fair criticism, but Vulkan hasn't exactly been grabbing market share either.
That Apple hasn't invested in Vulkan is a fair criticism, but Vulkan hasn't exactly been grabbing market share either.
Was their lack of OpenCL adoption on the trashcan Mac Pro really all attributable to OpenCL?
Or was it because the best GPU option it ever had was the FirePro D700 from 2014?
I guess you could buy a bunch of eGPU enclosures and hook up better GPUs over Thunderbolt (I think those ports are effectively PCIe x4), but regardless of how much effort they may have put in on the software side, they didn't keep up with the hardware. And being a proprietary GPU module in a thermally limited environment, they didn't have 3rd parties keeping up with it for them.
Blender (specifically their Cycles rendering engine) was one piece of software that supported OpenCL on the Mac, and AMD put a bunch of work into getting that working as an alternative to CUDA. It's now been disabled on account of Apple deprecating OpenCL. Bummer. https://lists.blender.org/pipermail/bf-committers/2018-Decem...
Or was it because the best GPU option it ever had was the FirePro D700 from 2014?
I guess you could buy a bunch of eGPU enclosures and hook up better GPUs over Thunderbolt (I think those ports are effectively PCIe x4), but regardless of how much effort they may have put in on the software side, they didn't keep up with the hardware. And being a proprietary GPU module in a thermally limited environment, they didn't have 3rd parties keeping up with it for them.
Blender (specifically their Cycles rendering engine) was one piece of software that supported OpenCL on the Mac, and AMD put a bunch of work into getting that working as an alternative to CUDA. It's now been disabled on account of Apple deprecating OpenCL. Bummer. https://lists.blender.org/pipermail/bf-committers/2018-Decem...
> Was their lack of OpenCL adoption on the trashcan Mac Pro really all attributable to OpenCL?
I'm not sure I follow you here. The trash bin Mac Pro was flawed from day 1 and the fact that it's seen few upgrades (and no significant upgrades) in the 6 years since hasn't helped it a bit. I'm not attributing the failure of the Mac Pro to OpenCL, it flopped all on it's own.
I'm not sure I follow you here. The trash bin Mac Pro was flawed from day 1 and the fact that it's seen few upgrades (and no significant upgrades) in the 6 years since hasn't helped it a bit. I'm not attributing the failure of the Mac Pro to OpenCL, it flopped all on it's own.
I'm not attributing the failure of the Mac Pro to OpenCL, I'm attributing the failure of OpenCL to the Mac Pro.
If they wanted OpenCL to unseat CUDA (or even compete with it) for professional GPU compute users, they needed competitive GPU hardware, and they didn't have it.
If they wanted OpenCL to unseat CUDA (or even compete with it) for professional GPU compute users, they needed competitive GPU hardware, and they didn't have it.
There was plenty of OpenCL shipping with AMD on other platforms. Apple is not interested in a market competitor to CUDA, only an alternative since they don't ship Nvidia GPUs across their lineup.
Vulkan Shading Language as it stands, is likely a non starter, you're right. That explains the lack of adoption.
That said, I wasn't advocating to try and beat that particular dead horse. I was advocating for OpenCL. I understand why the Metal Shading Language is superior, but OpenCL is still very good, and works across platforms to boot.
CUDA and MSL are really nice. I just wish both NVidia and Apple would add to OpenCL and let the industry move forward with that standard and the ability to use whatever hardware we wanted.
Now all that said, I also understand Apple's hesitancy with OpenCL as well. It's definitely one of those "fool me once, shame on you" kind of things.
That said, I wasn't advocating to try and beat that particular dead horse. I was advocating for OpenCL. I understand why the Metal Shading Language is superior, but OpenCL is still very good, and works across platforms to boot.
CUDA and MSL are really nice. I just wish both NVidia and Apple would add to OpenCL and let the industry move forward with that standard and the ability to use whatever hardware we wanted.
Now all that said, I also understand Apple's hesitancy with OpenCL as well. It's definitely one of those "fool me once, shame on you" kind of things.
Apple created OpenCL and donated it to Khronos.
The point of the trash can Mac Pro, was to use OpenCL to leverage two mid level GPUs as a cheaper and higher performance alternative to one high end and expensive GPU.
Developers never really adopted OpenCL, and the whole idea was dropped.
The point of the trash can Mac Pro, was to use OpenCL to leverage two mid level GPUs as a cheaper and higher performance alternative to one high end and expensive GPU.
Developers never really adopted OpenCL, and the whole idea was dropped.
Plus Khronos, as usual, was too C focus while Apple wanted to go into another direction.
Note how all proprietary shading languages are actually C++ dialects.
Only after loosing to the multiple language CUDA eco-system did Khronos start discussing about supporting C++, and even today it isn't as if OEMs are racing to bring SYCL drivers into the market.
Note how all proprietary shading languages are actually C++ dialects.
Only after loosing to the multiple language CUDA eco-system did Khronos start discussing about supporting C++, and even today it isn't as if OEMs are racing to bring SYCL drivers into the market.
First OpenCL needs to make it to use C++, Fortran, Julia, .NET, Java as easy as CUDA.
You can use Vulkan as a pretty much direct replacement for OpenCL
No you can't, because Vulkan forbids the kernel execution model. So that's a huge gotcha that a lot of beginners fall into. Only the shader execution model is usable in Vulkan.
Both Vulkan Shader Language and OpenCL get you SPIR-V code, but they are not drop in replacements for each other.
In practice, you have to use CUDA or OpenCL. CUDA, because everyone uses it. OpenCL because it runs everywhere and you can easily translate all the opensource CUDA into OpenCL without as many gotchas as trying to get to Vulkan Shading Language.
Both Vulkan Shader Language and OpenCL get you SPIR-V code, but they are not drop in replacements for each other.
In practice, you have to use CUDA or OpenCL. CUDA, because everyone uses it. OpenCL because it runs everywhere and you can easily translate all the opensource CUDA into OpenCL without as many gotchas as trying to get to Vulkan Shading Language.
What's so bad with rewriting your kernels for Vulkan compute? This is what I have done up to this point as I refuse to use CUDA
OpenCL doesn't run on Android.
Google has the poorly documented C99 dialect named Renderscript.
Some OEMs do actually ship OpenCL drivers, which can only be safely accessed via a device specific SDK.
Google has the poorly documented C99 dialect named Renderscript.
Some OEMs do actually ship OpenCL drivers, which can only be safely accessed via a device specific SDK.
Metal predates vulkan by over two years. If anything vulkan is a response to it, not the other way around.
Further, the article and the website are intentionally and blatently biased
Seems like an unnecessary criticism. It's an Apple fan blog, not journalism. Nobody is going to Apple Insider for balanced information about tech trends.
Seems like an unnecessary criticism. It's an Apple fan blog, not journalism. Nobody is going to Apple Insider for balanced information about tech trends.
AppleInsider is really excessively biased, even for an Apple-focused site. I'm an Apple user from way back and I rarely find their opinion pieces useful.
I agree. At first glance, they serve the same niche, but in reality there is a huge difference in credibility between AppleInsider and MacRumors.
(I don't have a relationship with either site.)
(I don't have a relationship with either site.)
> Nobody is going to Apple Insider for balanced information about tech trends.
Many people are going to click on an HN link and assume it's a reasonably objective technical source. I didn't realize it was an Apple fan blog until I was well into the article.
Many people are going to click on an HN link and assume it's a reasonably objective technical source. I didn't realize it was an Apple fan blog until I was well into the article.
I like to think the average Hackernews is a bit more savvy than to assume all or even most links here are objective. Still, there's no harm in saying "yo dawg, this article has an agenda, so just be aware of that when you read."
The name of the site "Apple Insider" didn't give it away?
Sorry if I don't know the background of every website on the Internet. There are a lot of people who use an Apple computer because they were the best choice at the time they purchased the computer, and might even have non-Apple computers they'd like to use also, not because they've been baptized at the Church of Jobs to fight in the Cook army to defend the motherland and conquert the rest of the world.
It isn't just that it was biased, but ridiculously so. It is sycophantic enough to make one wonder if it was a press release if I didn't know better that Apple the corporation wouldn't be writing these.
The praise is lavish enough and thin on substance to make it offensive to the taste if you were expecting any kind of real substance on Metal or direction for it.
The praise is lavish enough and thin on substance to make it offensive to the taste if you were expecting any kind of real substance on Metal or direction for it.
>Metal is racing against Vulkin as well, because Apple needed to have their own standard they owned.
Wait? What?
I'm pretty sure Metal was around long before Vulkan?
I think it would be more accurate to say that Apple and MS should switch to Vulkan.
Wait? What?
I'm pretty sure Metal was around long before Vulkan?
I think it would be more accurate to say that Apple and MS should switch to Vulkan.
Not exactly. Its probably more accurate to say Apple wasn't willing to wait for Vulkan to be shippable and made their own. Metal, Vulkan, Mantle and DX12 are all part of the same industry wide movement.
Metal and Vulkan's predecessor, Mantle, were under development at the same time, although Mantle was announced to the public several months sooner than Metal.
Mantle was released before Metal.
I think it's worth noting that Mantle was proprietary, and Vulkan is an open standard that was later spinned off it.
I think it's worth noting that Mantle was proprietary, and Vulkan is an open standard that was later spinned off it.
> Mantle was released before Metal.
Metal was released soon after and then as a finished "product" in iOS. It likely has had more than a year in development inside Apple before the release too.
You make it almost sound like they coughed up Metal in the few months after Mantle was shown.
Metal was released soon after and then as a finished "product" in iOS. It likely has had more than a year in development inside Apple before the release too.
You make it almost sound like they coughed up Metal in the few months after Mantle was shown.
So the release of Metal to the public was over 6 months after the release of Mantle.
But my point was that Apple couldn't use Mantle even if they wanted to, because it was proprietary.
But my point was that Apple couldn't use Mantle even if they wanted to, because it was proprietary.
Apple deprecates everything all the time.
If they want, they can switch. In the long run Metal either: has no future; or must be opened; or will remain a proprietary tech with little advantage and recurring dev costs for both Apple and app devs.
With the existing competition, I personally don't think it will be both opened AND widely adopted. Probably already too late. So either you really want to get on Apple computers now, or the tech is, IMO, basically irrelevant.
Whereas OpenCL is, yes, laborious, but still relevant in the open world. And Vulkan is also used across different vendors.
Apple can get away with their current "my way or the highway" attitude solely because of their user base actually not negligible, and somehow "rich". Devs are not liking the platform a lot, and I phrased that carefully to be kind. Most of their "pro" product have been discontinued or have become laughable. The new Mac Pro is an interesting counter-example, but for a very niche market; which means that even with their pile of cash, they choose to concentrate instead of attempting to conquer new markets.
Given they sell basically luxury products, it is doubtful this will remain like that forever. They might transition their model, but I'm not sure toward what. Everybody talks all the time about services, but that's clearly not what vendors of gadgets are relying on for now. As for artificially monopolistic or quasi-monopolistic "app stores" and/or "clouds", I do not even consider that a "service", and they obviously rely completely on the consumable gadget model.
If they want, they can switch. In the long run Metal either: has no future; or must be opened; or will remain a proprietary tech with little advantage and recurring dev costs for both Apple and app devs.
With the existing competition, I personally don't think it will be both opened AND widely adopted. Probably already too late. So either you really want to get on Apple computers now, or the tech is, IMO, basically irrelevant.
Whereas OpenCL is, yes, laborious, but still relevant in the open world. And Vulkan is also used across different vendors.
Apple can get away with their current "my way or the highway" attitude solely because of their user base actually not negligible, and somehow "rich". Devs are not liking the platform a lot, and I phrased that carefully to be kind. Most of their "pro" product have been discontinued or have become laughable. The new Mac Pro is an interesting counter-example, but for a very niche market; which means that even with their pile of cash, they choose to concentrate instead of attempting to conquer new markets.
Given they sell basically luxury products, it is doubtful this will remain like that forever. They might transition their model, but I'm not sure toward what. Everybody talks all the time about services, but that's clearly not what vendors of gadgets are relying on for now. As for artificially monopolistic or quasi-monopolistic "app stores" and/or "clouds", I do not even consider that a "service", and they obviously rely completely on the consumable gadget model.
Apparently everyone keeps forgetting Sony.
Also, Vulkan is quickly becoming the lingua franca of graphics APIs. Vulkan can be implemented on top of Metal, which means that developers have next to no reason to implement Metal directly.
Moreover, it is even implemented[1] by the Khronos Group itself.
[1] https://github.com/KhronosGroup/MoltenVK
[1] https://github.com/KhronosGroup/MoltenVK
Actually, it's Valve paying the bills for the MoltenVK guy so that MoltenVK is part of Khronos.
Basically, Valve is saying: "OS X is a completely useless environment but has lots of people who spend more money than Windows users. So, we can make lots of money if we can maintain one codebase by writing a shim wrapper even if we have to eat performance."
Basically, Valve is saying: "OS X is a completely useless environment but has lots of people who spend more money than Windows users. So, we can make lots of money if we can maintain one codebase by writing a shim wrapper even if we have to eat performance."
Performance could be a reason. It’s highly likely that implementing a low level graphics API on top of another low-level graphics API will have some performance gotchas here and there.
On which platform exactly?
It’s also important to note that Vulkan at this point is as fragmented as OpenGL as far as extension support coverage goes.
It’s also important to note that Vulkan at this point is as fragmented as OpenGL as far as extension support coverage goes.
CUDA is not an "open standard"
That was the same paragraph I stopped on and thought, “How biased is this?”
All mentions of the machine learning efforts seemed vague, as well.
That was the main reason for me for reading the article.
All mentions of the machine learning efforts seemed vague, as well.
That was the main reason for me for reading the article.
Without the ability to spin Osx instances up on the cloud, I don't see Metal making a dent in CUDA.
The cloud is staggeringly more expensive than building your own workstation. Like a couple of weeks of on-demand GPU instances on AWS Virginia costs about as much as a machine with 2 RTX 2080 cards in it that will stay performant for at least a couple years.
But coming back to the Mac Pro, unless you need Apple-specific software, the same is true compared to Ryzen/ThreadRipper + NVidia cards. The Mac costs 2-3x as much while delivering less performance.
At least the cloud can scale horizontally, the Mac Pro is just slow and inefficient.
But coming back to the Mac Pro, unless you need Apple-specific software, the same is true compared to Ryzen/ThreadRipper + NVidia cards. The Mac costs 2-3x as much while delivering less performance.
At least the cloud can scale horizontally, the Mac Pro is just slow and inefficient.
You forget that using the cloud you can spin up 9 ladies to have a baby in a month, or 270 ladies to have a baby in a day.
Why is that? Shouldn't competition drive cloud prices closer to ownership prices?
The average corporate IT department is rubbish at doing computing. Easier and quicker to outsource than doing it in house. But nVidia sell GPU appliances (DGX) for these on-prem customers.
Basically, expertise is expensive and comes in $200k/year increments. You can use a lot of cloud GPU for that much money.
Basically, expertise is expensive and comes in $200k/year increments. You can use a lot of cloud GPU for that much money.
Its because NVIDIA requires Teslas in the cloud, which while more powerful than 2080 ti's, cost roughly 6-8x as much.
How does that work? If I buy a 2080 Ti and then decide to use it in an internet-hosted box that I rent out to other people, the first-sale doctrine should tell Nvidia to piss off if they have a problem with it.
When you are operating at any kind of scale you need the Telsa packaging (airflow, connectors, power) and testing (running many in a system). The consumer desktop cards cause lots of trouble.
Also the consumer cards have artificially small memory sizes (e.g. 11GB max) which painfully constrains DL jobs.
No manufacturer is allowed to build Tesla-like cards. Theoretically AMD could crush the nVidia profit margins by releasing cheap data center boards, but their developer support is rubbish and they want that high margin cash too.
Also the consumer cards have artificially small memory sizes (e.g. 11GB max) which painfully constrains DL jobs.
No manufacturer is allowed to build Tesla-like cards. Theoretically AMD could crush the nVidia profit margins by releasing cheap data center boards, but their developer support is rubbish and they want that high margin cash too.
.. what this means, is that Apple is competing against the Titan/NVIDIA hardware designers to make better compute power available at scale, and in a way which makes sense across consumer/pro boundaries.
In that context, the Mac Pro doesn't sound too bad a proposition. I say that as someone who recently built a dual-Titan/AMD Ryzen system, and while the pain of the build is almost gone away .. I do lust after that sexy Apple box, being plug 'n play and all ..
In that context, the Mac Pro doesn't sound too bad a proposition. I say that as someone who recently built a dual-Titan/AMD Ryzen system, and while the pain of the build is almost gone away .. I do lust after that sexy Apple box, being plug 'n play and all ..
Intel competes with nVidia on high end GPU hardware and so far (KL and KF) are doing an abysmal job of it, despite using their CPU control to lock nVidia out of the CPU bus.
Apple can't really compete except in mobile GPUs, which is all about power constraints set to single digits Watts, vs >100W for server. That isn't all bad for Apple, there is lots of inference to be done, but by refusing nVidia hardware they impose a developer hurdle.
I'm looking forward to people putting 2080s into the new Mac Pro and seeing how reliable it is.
Apple can't really compete except in mobile GPUs, which is all about power constraints set to single digits Watts, vs >100W for server. That isn't all bad for Apple, there is lots of inference to be done, but by refusing nVidia hardware they impose a developer hurdle.
I'm looking forward to people putting 2080s into the new Mac Pro and seeing how reliable it is.
Nvidia wouldn't have prohibited people from using GeForce cards in data centers if people weren't do it.
People do try, but it isn't the basis for a successful computing platform. Works for block chain (though AMD delivers more flops/$ for simple sha-ing grunt work) and specific workloads where you have time and expertise but not much cash.
As for nVidia banning it, if you've the cash you can buy cards, just becomes painful. nVidia were doing it more because the GPGPU demand was choking the supply to graphics customers, and later dumping obsolete (for crunching) cards on the market en masse, interfering with the mid-tier card sales channel.
As for nVidia banning it, if you've the cash you can buy cards, just becomes painful. nVidia were doing it more because the GPGPU demand was choking the supply to graphics customers, and later dumping obsolete (for crunching) cards on the market en masse, interfering with the mid-tier card sales channel.
Because nvidia's driver licensing terms require you not to be using the consumer stuff in a datacenter.
What if you're running Linux with the nouveau driver?
It's irrelevant. You need the CUDA SDK and the CuDNN SDK both of which have license agreements.
Edit: You may also need the official Nvidia driver. I have never run anything with the OSS drivers.
Edit: You may also need the official Nvidia driver. I have never run anything with the OSS drivers.
Gotcha
I believe they get around this by applying the restrictions to the software licensing for the CUDA libraries you have to download separately when installing things like TensorFlow.
There’s a high cost of entry (onboarding lots of customers, building data centers, writing the management software, etc.), so there isn’t much competition. The market just isn’t efficient in this case.
I think it does for stuff like storage, but transactional and heavy data processing are still cheaper to do on-prem from what I've seen.
If you are doing serious training with on-demand instances you are doing it wrong.
If your training takes more than an hour, you really need to checkpoint it periodically. If you have periodic checkpoints you can use spot instances and pay 10% or less of what on-demand would cost.
If your training takes more than an hour, you really need to checkpoint it periodically. If you have periodic checkpoints you can use spot instances and pay 10% or less of what on-demand would cost.
1) Even with checkpoints and spot instances, the initial REPL development process needs to happen somewhere.
2) Where are you seeing 10%? More realistically spot instances are 25-30% of the cost. And if so fine, 6 weeks of machine time == dedicated workstation.
2) Where are you seeing 10%? More realistically spot instances are 25-30% of the cost. And if so fine, 6 weeks of machine time == dedicated workstation.
Yeah, one workstation. If you need to build out 1,000x as many GPUs, the cloud becomes more economical. And that's where the money is, in large customers, not someone who needs 1 or 2 cloud GPUs.
Agreed. I expect Metal to be used by game engines that target iOS, but there's way too much hardware tax involved for it to supplant CUDA or OpenCL for GPU programming workloads.
MacStadium exists.
MacStadium is really great, but it’s relatively expensive for a given spec and not as simple/agile as some other bare metal platforms. Nothing against MacStadium, though, they seem to do all they can to drag Mac kicking and screaming into the data center.
I was a MacStadium customer for years, and I really liked the products, but they are very expensive.
In all honesty, with Metal limited to just Apple and Vulkan representing roughly “everyone else,” will this even be a fair fight? This could be a horrendous prediction, but I see Metal as the modern-day Betamax. There’s nothing wrong with it, but is this how you win a competition of APIs? I have enormous doubts.
For deep learning, scientific computing, basically all other GPGPU stuff, it's all (>95%) CUDA. Vulkan is essentially unused.
No doubt. In fact this is still true for virtually all GPGPU compute as far as I know. It’s possible Vulkan Compute will never gain serious traction, and it will remain CUDA vs the world. I kind of hope not for sake of open standards.
Vulkan is definitely not “everyone else”.
On Windows it is only supported on classical Win32, on Win32 and UWP sandboxes only DirectX is supported.
XBox naturally is DirectX only.
On Sony PS4 there is LibGNM and doesn't appear PS 5 team will care about Vulkan.
Nintendo Switch does support Vulkan, as secondary 3D API, if you want to go full speed, there is NVN for that.
On Android, Google was forced to make Vulkan a required API on Android 10, because since its introduction as optional 3D API, outside Samsung and Google very few OEMs cared to ship good working Vulkan drivers, if at all.
It is so significant that Google is yet to add Vulkan market share information to the Android dashboard.
On Windows it is only supported on classical Win32, on Win32 and UWP sandboxes only DirectX is supported.
XBox naturally is DirectX only.
On Sony PS4 there is LibGNM and doesn't appear PS 5 team will care about Vulkan.
Nintendo Switch does support Vulkan, as secondary 3D API, if you want to go full speed, there is NVN for that.
On Android, Google was forced to make Vulkan a required API on Android 10, because since its introduction as optional 3D API, outside Samsung and Google very few OEMs cared to ship good working Vulkan drivers, if at all.
It is so significant that Google is yet to add Vulkan market share information to the Android dashboard.
Vulkan is “everyone else” if we’re only considering serious contenders for a next generation graphics and compute API. Machine-specific APIs don’t have a long shelf life, pretty much never have. DirectX does compete but it’s even further behind than Apple in terms of ecosystem coverage. Is anyone using DirectCompute?
And also, UWP is practically dead in the water, no need to beat that horse.
Game consoles are their own beast. It would be nice if they provided either Vulkan or GL, for porting lower tech software, but otherwise it’s unclear whether a generalized API would make sense in such a specialized device.
And also, UWP is practically dead in the water, no need to beat that horse.
Game consoles are their own beast. It would be nice if they provided either Vulkan or GL, for porting lower tech software, but otherwise it’s unclear whether a generalized API would make sense in such a specialized device.
UWP is pretty much alive.
WinUI 3.0 and XAML Islands roadmap at BUILD 2019
https://mybuild.techcommunity.microsoft.com/sessions/77008
React Native for Windows reimplementation
https://github.com/microsoft/react-native-windows
React Native @ Microsoft, https://www.youtube.com/watch?v=IUMWFExtDSg
And even if one disregards the fact that all new Windows 10 APIs are UWP based, the sandbox also applies to Win32 apps deployed via the store or MSIX packages.
As for DirectCompute, game developers naturally.
WinUI 3.0 and XAML Islands roadmap at BUILD 2019
https://mybuild.techcommunity.microsoft.com/sessions/77008
React Native for Windows reimplementation
https://github.com/microsoft/react-native-windows
React Native @ Microsoft, https://www.youtube.com/watch?v=IUMWFExtDSg
And even if one disregards the fact that all new Windows 10 APIs are UWP based, the sandbox also applies to Win32 apps deployed via the store or MSIX packages.
As for DirectCompute, game developers naturally.
Do we know marketshare of UWP games versus Steam and Epic Games Store?
I realize anecdotes are worthless, but I know literally nobody that uses Windows Store to buy anything. If they had used it to buy books, they would already be SoL. Categorizing Windows Store as anything but a miserable option people use in any other condition than begrudgingly is a concept that is genuinely new to me, and I say this as someone that wanted to like Windows 10. Microsoft sent evangelists to my university twice while I was there in an attempt to push more developers towards UWP and the skepticism in the room was damn near palpable. To be fair, this was before UWP apps could run in windows without a Stardock utility (the Windows 8 era.)
UWP is not new. I believe both Chromium and Firefox have attempted to support it and ultimately given up (correct me if I’m wrong.) It may be gaining a bit of developer traction now, but I don’t exactly see the world shifting around it, in a world where most apps are Electron and most games are on Steam, and pretty much everything else is “on the cloud.”
I realize anecdotes are worthless, but I know literally nobody that uses Windows Store to buy anything. If they had used it to buy books, they would already be SoL. Categorizing Windows Store as anything but a miserable option people use in any other condition than begrudgingly is a concept that is genuinely new to me, and I say this as someone that wanted to like Windows 10. Microsoft sent evangelists to my university twice while I was there in an attempt to push more developers towards UWP and the skepticism in the room was damn near palpable. To be fair, this was before UWP apps could run in windows without a Stardock utility (the Windows 8 era.)
UWP is not new. I believe both Chromium and Firefox have attempted to support it and ultimately given up (correct me if I’m wrong.) It may be gaining a bit of developer traction now, but I don’t exactly see the world shifting around it, in a world where most apps are Electron and most games are on Steam, and pretty much everything else is “on the cloud.”
That is the big mistake many make, UWP is much more than just store apps, it is the evolution of COM, the slow rewrite of making Windows ABI an OOP one as originally planned for Longhorn.
All major Windows 10 APIs are UWP only, so even Chromium and Firefox need to use them, in case they need to access OS modern Windows 10 features.
Market share for games, I don't know, naturally plenty of Microsoft Studios games are there.
Personally I never bother with third party stores. Either I own the game in physical form or respective OS/console platform sales channels.
Although I expect the Steam market share to be quite big.
Finally, sandboxing any Win32, .NET or UWP is a feature of the new MSIX packages.
So even if companies are not directly deploying via the store, it doesn't mean it doesn't get sandboxed.
All major Windows 10 APIs are UWP only, so even Chromium and Firefox need to use them, in case they need to access OS modern Windows 10 features.
Market share for games, I don't know, naturally plenty of Microsoft Studios games are there.
Personally I never bother with third party stores. Either I own the game in physical form or respective OS/console platform sales channels.
Although I expect the Steam market share to be quite big.
Finally, sandboxing any Win32, .NET or UWP is a feature of the new MSIX packages.
So even if companies are not directly deploying via the store, it doesn't mean it doesn't get sandboxed.
UWP and Windows store are orthogonal (since 2016-17). UWP apps can be installed from the web or other stores and non-UWP Win32 apps can be in the Windows store. So "UWP versus Steam" doesn't really make sense.
Some form of this argument has been a criticism of Apple from time immemorial.
At first it was apple's way or the highway.
Then apple started integrating well with everyone. They adopted intel cpus. Apple hardware let you have your cake and eat it too - you could run Mac OS or Windows or both. You could buy a system with intel, or ati (amd) or nvidia. You could put hard disks or ssds in your machine. You had choices. Mac laptops became the laptops that everyone wanted.
Now they're going back the other way.
Then apple started integrating well with everyone. They adopted intel cpus. Apple hardware let you have your cake and eat it too - you could run Mac OS or Windows or both. You could buy a system with intel, or ati (amd) or nvidia. You could put hard disks or ssds in your machine. You had choices. Mac laptops became the laptops that everyone wanted.
Now they're going back the other way.
In the context of this article, “everyone else” is CUDA. I think at this stage we can all agree that OpenCL has pretty much lost. While it is entirely possible that Vulkan will eventually manage to overtake all, has it even been making a dent in CUDA's market share so far?
That said, given Apple's hardware cost, I don't think Metal will make a big dent either.
That said, given Apple's hardware cost, I don't think Metal will make a big dent either.
I don’t think Vulkan Compute has really taken off at all. But, I suspect it still has a chance to do so if it manages to continue to gain mindshare as a graphics API. That really remains to be seen.
Does Vulkan work on Xbox and PS?
Excellent question, but let’s be clear: it’s more of a question of whether or not Xbox or PlayStation ship Vulkan implementations. As far as I know, PlayStation is traditionally proprietary APIs, and you would need a third party implementation, if one exists. As for Xbox, I assume Xbox is still a modified Direct3D API for graphics.
I assume you didn’t mention Switch because it, somewhat famously, does actually ship with Vulkan support natively. Which is cool.
Of course, even though video game consoles continue to converge into looking like computers, developers still don’t and can’t treat them as such. Sure, Switch runs Vulkan but that doesn’t mean you can compile a Vulkan game and ship it to the eShop. Same for a DirectX game on Xbox. Consoles are, by nature, very proprietary, and much more frugal than general purpose computing platforms.
Does adoption of Vulkan for game consoles matter? Maybe, but I’d guess probably not. It might help the consoles attract developers, but at the end of the day every console is going to get its own port with a decent amount of retooling to better suit the platform, especially in the case of Switch which is not a terribly high end piece of hardware in this day and age.
I assume you didn’t mention Switch because it, somewhat famously, does actually ship with Vulkan support natively. Which is cool.
Of course, even though video game consoles continue to converge into looking like computers, developers still don’t and can’t treat them as such. Sure, Switch runs Vulkan but that doesn’t mean you can compile a Vulkan game and ship it to the eShop. Same for a DirectX game on Xbox. Consoles are, by nature, very proprietary, and much more frugal than general purpose computing platforms.
Does adoption of Vulkan for game consoles matter? Maybe, but I’d guess probably not. It might help the consoles attract developers, but at the end of the day every console is going to get its own port with a decent amount of retooling to better suit the platform, especially in the case of Switch which is not a terribly high end piece of hardware in this day and age.
Switch also has their own proprietary API, NVN.
Vulkan is a kind of addendum.
Vulkan is a kind of addendum.
Sure: it’s clear Vulkan is made to attract developers. I don’t think there’s any delusion that a unified API would really mean you didn’t have to port to each console individually; you need more fine grained optimization for most games still, especially in Switch’s case. Eventually this may stop being true, but as long as a $300 laptop has trouble gaming, it would be unfair to expect a $300 portable game console to run unmodified games significantly better. In this case, the API only matters to a smaller degree.
Their GPU's support it, of course they are closed systems so I have no idea how you would get it on there easily.
I’ve been exploring Metal a lot in the past year, and I really enjoy working with it.
This article has a lot of interesting historical bits, but conflates a lot. Maybe Jobs hoped to take on the high-end graphics market, but my understanding is that the NeXT cube was fairly underpowered. It was its application development environment which made it a cult classic. (And arguably what led the the success of MacOS and iOS.)
The Mac Pro is definitely reminiscent of a time where SGI had some of the sexiest machines available. There’s always been the “Apple Tax”, but there’s also always been people willing to pay it because they love the Apple ecosystem, the aesthetics of the platform.
This article has a lot of interesting historical bits, but conflates a lot. Maybe Jobs hoped to take on the high-end graphics market, but my understanding is that the NeXT cube was fairly underpowered. It was its application development environment which made it a cult classic. (And arguably what led the the success of MacOS and iOS.)
The Mac Pro is definitely reminiscent of a time where SGI had some of the sexiest machines available. There’s always been the “Apple Tax”, but there’s also always been people willing to pay it because they love the Apple ecosystem, the aesthetics of the platform.
Given the hefty price of the new Mac Pro, the lack of dense, rackable hardware setups, I don't see how it could make any significant dent in the 3D market.
They said the new Mac Pro will come in a rack mounted variant at the WWDC presentation. Rebirth of the Xserve ;P
So many 3D folks are fond of Mac that I'm surprised there isn't an aftermarket company dedicated to fitting Mac Pro guts into a rackable chassis. Of course, even then you'd be left with the problem of what to do with all those hollowed out cheese graters...
It's fairly standard for rendering/games engines to support native graphics apis, they're built to be cross platform.
Not to mention machine learning is a totally different market, using OS X on workstations would be counterproductive as there isn't any feasible server solutions to run production data on.
Also the Tegra chips aren't irrelevant, they're powering the switch and extremely popular for drone/robotics application processors.
This entire article is biased beyond belief.
Not to mention machine learning is a totally different market, using OS X on workstations would be counterproductive as there isn't any feasible server solutions to run production data on.
Also the Tegra chips aren't irrelevant, they're powering the switch and extremely popular for drone/robotics application processors.
This entire article is biased beyond belief.
The Mac Pro will come in a rackable server chassis version. That's a detail from the announcement a lot of people missed. Presumably Apple intends for the new hardware to be deployable Xserve style, not just workstations.
https://i.imgur.com/D1HaH9l.png
https://i.imgur.com/D1HaH9l.png
Competition is generally good, but competing standards are bad, especially when they have no real advantages over each other. Imagine if every platform had its own incompatible version of C (ok, yes there are incompatibilities but they are not there by intention).
If you want to win me over as a developer, do it the right way. Provider superior tooling and win a customer base with superior implementation.
If you want to win me over as a developer, do it the right way. Provider superior tooling and win a customer base with superior implementation.
I'm not sure it's that simple when you're talking about needing to evolve hardware design and software toolkit together. NVidia has been ahead of everyone else largely because they skip all the coordination overhead and design CUDA to just work on their hardware, and put their energy into making that hardware + software combination better and better without regard for what everyone else is doing. If Apple wants to compete it's hard to see how they could without adopting a similar approach.
What I think is more realistic is that things like Vulcan will have Metal and CUDA adapters, etc., and that developers who don't need bleeding edge performance as much as they need broad compatibility will be able to use that.
In other words it's the same tradeoff as we've seen in software for decades -- you can write a fully-optimised native application per operating system, or you can use a cross-platform toolkit (increasingly the web) which can do a nice job but lacks some of the power and polish that a native application can deliver.
What I think is more realistic is that things like Vulcan will have Metal and CUDA adapters, etc., and that developers who don't need bleeding edge performance as much as they need broad compatibility will be able to use that.
In other words it's the same tradeoff as we've seen in software for decades -- you can write a fully-optimised native application per operating system, or you can use a cross-platform toolkit (increasingly the web) which can do a nice job but lacks some of the power and polish that a native application can deliver.
What an incredibly Cool-Aid guzzling piece. Manages to get historical time line right but has totally out of kilter understanding of the reasons why. And thinking Apple can supplant CUDA with their own proprietary tech is completely delusional. The lack of an nVidia GPU is a significant drawback to using it as a workstation, and Apple is foolish to have gone the AMD only route.
[deleted]
As an aside, what's this about "Microsoft and Intel worked to steal Apple's code representing proprietary video acceleration techniques" back in the day?
It's before my time, and the citation is a press release. Any one remember that?
It's before my time, and the citation is a press release. Any one remember that?
Code written under contract for a port of QuickTime to Windows later showed up in Microsoft's Video for Windows product.
>The lawsuit, filed on December 6, 1994, alleged that the San Francisco Canyon used some of the code developed under contract to Apple, in their additions to Video for Windows. Apple expanded the lawsuit to include Intel and Microsoft on February 10, 1995, alleging that Microsoft and Intel knowingly used the software company to aid them in stealing several thousand lines of Apple's QuickTime code in their effort to improve the performance of Video for Windows.
On March 3, 1995, a federal judge issued a temporary restraining order that prohibited Microsoft from distributing its current version of Video for Windows.[1] Microsoft subsequently released version 1.1e of Video for Windows, that removed all of the code contributed by San Francisco Canyon, stating in the release notes "does not include the low-level driver code that was licensed from Intel Corporation." Later testimony in the Microsoft anti-trust trial revealed that, at the time, Apple was threatening Microsoft with a multi-billion dollar lawsuit over the allegedly stolen code, and in return Bill Gates was threatening with the cancellation of Office for the Mac.[2]
https://itlaw.wikia.org/wiki/Apple_v._San_Francisco_Canyon
Microsoft and Apple eventually settled and cross licensed their patent portfolios.
>The lawsuit, filed on December 6, 1994, alleged that the San Francisco Canyon used some of the code developed under contract to Apple, in their additions to Video for Windows. Apple expanded the lawsuit to include Intel and Microsoft on February 10, 1995, alleging that Microsoft and Intel knowingly used the software company to aid them in stealing several thousand lines of Apple's QuickTime code in their effort to improve the performance of Video for Windows.
On March 3, 1995, a federal judge issued a temporary restraining order that prohibited Microsoft from distributing its current version of Video for Windows.[1] Microsoft subsequently released version 1.1e of Video for Windows, that removed all of the code contributed by San Francisco Canyon, stating in the release notes "does not include the low-level driver code that was licensed from Intel Corporation." Later testimony in the Microsoft anti-trust trial revealed that, at the time, Apple was threatening Microsoft with a multi-billion dollar lawsuit over the allegedly stolen code, and in return Bill Gates was threatening with the cancellation of Office for the Mac.[2]
https://itlaw.wikia.org/wiki/Apple_v._San_Francisco_Canyon
Microsoft and Apple eventually settled and cross licensed their patent portfolios.
Oops, I posted at the same time. Thanks for the summary.
"although Intel certainly knew that Canyon [Co.] had developed key parts of the code for Apple, it did not specify that this must be undertaken in a clean room[...]A month later, Canyon delivered the program to Intel containing code that was an exact copy of the code that it had previously delivered to Apple. Intel gave this code to Microsoft as part of a joint development program called Display Control Interface. Canyon admitted that it had copied to Intel code developed for and assigned to Apple. In September 1994, Apple's software was distributed by Microsoft in its developer kits, and in Microsoft's Video for Windows version 1.1d. Apple noticed a suspicious improvement in the performance of Microsoft's video driver"
"Following a bizarre intervention that took the form of a late-night telephone call to Microsoft head-lawyer Bill Neukom by Ann Bingaman, the head of the DoJ's antitrust division, in response to a request from Edward Stead, then Apple's general counsel, this was at last supplied. The next day, Apple added Microsoft to the list of defendants in the San Jose court case. The sub-text of the dispute also began to emerge: 'Apple is also claiming that Microsoft has been using the code in question to mess up [Apple's] attempts to make QuickTime a standard.'"
Ty folks.
"Following a bizarre intervention that took the form of a late-night telephone call to Microsoft head-lawyer Bill Neukom by Ann Bingaman, the head of the DoJ's antitrust division, in response to a request from Edward Stead, then Apple's general counsel, this was at last supplied. The next day, Apple added Microsoft to the list of defendants in the San Jose court case. The sub-text of the dispute also began to emerge: 'Apple is also claiming that Microsoft has been using the code in question to mess up [Apple's] attempts to make QuickTime a standard.'"
Ty folks.
If I remember correctly a company working with Apple had access to QuickTime source code, and this company just reused QuickTime when Intel and Microsoft approached it to create a video player.
[deleted]
For those that think Apple can't pull this off, remember that they dominate the developer laptop market. They just need to incrementally slip it in via software and hardware.
For example I recently found myself doing some video encoding via ffmpeg. The default install from brew supports videotoolbox (T2 chip accelerated) out of the box, and boy howdy is it fast. It smokes my multicore intel server optimized with vaapi.
Soon users will do a `pip install pytorch` on their dev laptop and get the metal-optimized version of it without even thinking twice. Apple already has their foot in the door.
For example I recently found myself doing some video encoding via ffmpeg. The default install from brew supports videotoolbox (T2 chip accelerated) out of the box, and boy howdy is it fast. It smokes my multicore intel server optimized with vaapi.
Soon users will do a `pip install pytorch` on their dev laptop and get the metal-optimized version of it without even thinking twice. Apple already has their foot in the door.
I don't know about dominate. From the most recent Stack Overflow survey, 25% of developers used Mac, 25% used Linux/BSD, and 50% used windows.
Maybe I should say it dominates for silicon valley tech companies and startups, which is manifestly obvious to anyone who works here.
Fair enough. I'm "valley-adjacent" and so I see plenty of that.
That would be amazing, but I'll believe it when I see it. So far Apple hasn't seemed to care at all about open tools like pytorch or tensorflow. An independent developer might be able to modify a video encoding library to support metal easily enough, but getting pytorch or tensorflow to work seems to require serious support, support that has yet to show itself.
You can play around with ML on your laptop, but serious work is typically done in the cloud. I use powerful Nvidia GPUs from my MacBook every day.
> One can be righteously indignant that Apple isn't subsidizing everyone else with support for their platforms, whether CUDA, Vulkan, or even Android. But such emotions won't have any bearing on the final outcome of who wins and who loses in the market for developing and commercializing the graphics technology of the future
Time for Apple to unstick from their nasty lock-in attitude, and to support Vulkan. Such sickening lock-in approach in development tools is so much '90s. Apple got frozen in time with having this attitude.
Metal isn't even a competitor to Vulkan, due to Metal being Apple only. So it's not a question of what will win. It's a question, whether Apple will remain in the dark age of lock-in or will unstick from it and will become a good citizen that collaborates instead of taxing developers.
Time for Apple to unstick from their nasty lock-in attitude, and to support Vulkan. Such sickening lock-in approach in development tools is so much '90s. Apple got frozen in time with having this attitude.
Metal isn't even a competitor to Vulkan, due to Metal being Apple only. So it's not a question of what will win. It's a question, whether Apple will remain in the dark age of lock-in or will unstick from it and will become a good citizen that collaborates instead of taxing developers.
Vulkan (MoltenVK) does seem to be a valid option for those heavily invested or interested in porting existing OpenGL projects (I plan on evaluating it):
https://github.com/KhronosGroup/MoltenVK
Either I completely missed some important things about PC history, or the author does not know at all what he is talking about:
e.g.:
> By 1991 ATI was selling dedicated GPU cards that worked independently from the CPU. By enhancing the gameplay of titles like 1993's "Doom"
Hm I'm sorry, what???
e.g.:
> By 1991 ATI was selling dedicated GPU cards that worked independently from the CPU. By enhancing the gameplay of titles like 1993's "Doom"
Hm I'm sorry, what???
The ATI Mach8 was a 8514/A graphics accelerator with no VGA core so it needed a separate base video card.
AFAIK Doom never had a 8514/A mode, but there where a very few games that did: https://www.classicdosgames.com/game/Mah_Jongg_-8514-.html
Back then accelerators where about GUI/windows acceleration and then the 3dfx came out...
AFAIK Doom never had a 8514/A mode, but there where a very few games that did: https://www.classicdosgames.com/game/Mah_Jongg_-8514-.html
Back then accelerators where about GUI/windows acceleration and then the 3dfx came out...
Acceleration in that era was about 2d drawing, most of the time for desktop env. Completely uninteresting for 3d games like Doom. Probably uninteresting for even 2d games unless the acceleration in question support direct sprite rendering (like video game consoles)
Anything that impedes NVIDIA is good news for open source.
I mean the whole article talks about how Apple wants to grab CUDA's market share with their own proprietary tech that is owned by Apple and only exists in Apple's walled garden. Not sure how much of a win for open source that is.
Everything that was impeding Microsoft was good news for open source. Until Chrome.
I'm happy for Apple to embrace gaming, but yet another proprietary non-cross platform API is not what we need. I will not be supporting metal.
Seems strange they don't mention Vulkan. While OpenGL will continue to be developed, Vulkan is lower-level and plays into the architecture of modern GPUs. Edit: I am wrong here and apparently can't find properly.
I'm not entirely confident that Metal will see widespread adoption become outside of iOS devices. And while that's a big market, it's on the opposite spectrum of the more powerful, and niche, Mac Pro.
I'm not entirely confident that Metal will see widespread adoption become outside of iOS devices. And while that's a big market, it's on the opposite spectrum of the more powerful, and niche, Mac Pro.
People who trust Apple are made to look like fools, every time. Consider using a compatibility layer rather than using Metal directly: chances are, your shaders will perform just as well, and you won't be tied to their cycles of betrayal and rug-pulling.
And, yes, that's a little mean of me, but I'm not kidding. In July 2010 he wrote three pages with illustrations about how Xcode 4 "could portend new HTML5 development tools" that delivered "solutions for parallel development tasks"; in April of that year, he wrote what might as well have been a short novel about how the iPad would "kill" DVDs, Microsoft Office, DVRs, and "idle moments." He at least used to fill his long, long articles with links that look like citations, but are actually just links to... earlier speculative articles he's written. Actual references tend to be very, very thin. He's also still remarkably committed to the notion that everything Apple does is mad genius four-dimensional chess, to the point where other bloggers in the Apple space including John Gruber (and, back when I could be described as "a blogger in the Apple space," me, I suppose) called him out for it.
The notion that Metal is a SECRET GRAND STRATEGY to replace CUDA is fascinating, it's just... not supported by any material evidence, despite the length of the article suggesting otherwise. In other words, it's pretty classic Dan Dilger.