Choice may come back in macOS, but it may be AMD and Intel ( depending upon Intel's discrete GPUs go). I don't think Apple actually wants it be one vendor, but not going to let someone throw Metal under the bus to get to two. If Intel does what Apple asks then they'll probably be in the mix. Shouldn't be a huge leap because Intel has been the largest GPU deployment on Macs and has been on board with Metal in a timely fashion the whole time.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
MP 7,1 AMD Big Navi is coming to Mac Pro and iMac Pro
- Thread starter high heaven
- Start date
- Sort by reaction score
Choice may come back in macOS, but it may be AMD and Intel ( depending upon Intel's discrete GPUs go). I don't think Apple actually wants it be one vendor, but not going to let someone throw Metal under the bus to get to two. If Intel does what Apple asks then they'll probably be in the mix. Shouldn't be a huge leap because Intel has been the largest GPU deployment on Macs and has been on board with Metal in a timely fashion the whole time.
I don't think Metal will be successful in the pro space (artists + scientists). The Mac marketshare is just too small for most to bother. There will be a few exceptions, like some Adobe apps, Otoy and such. But that will be about it.
I understand the raison d'être of Metal as a framework that powers most of the graphics stack, iOS games and other frameworks like ARKit. But Apple should maintain/embrace some cross-platform frameworks (openCL/Vulkan) if they want to attract pros to macOS. They seem way too confident about the chances of Metal in the pro space.
I understand the raison d'être of Metal as a framework that powers most of the graphics stack, iOS games and other frameworks like ARKit. But Apple should maintain/embrace some cross-platform frameworks (openCL/Vulkan) if they want to attract pros to macOS. They seem way too confident about the chances of Metal in the pro space.
I don't see developers/engineers leaving CUDA in verticals where it's kicking ass.
NVIDIA fostered CUDA until it got its own momentum. For Metal to succeed, it will need serious love from Apple to get devs to engage. Insert cart/horse analogy of choice here ___
NVIDIA fostered CUDA until it got its own momentum. For Metal to succeed, it will need serious love from Apple to get devs to engage. Insert cart/horse analogy of choice here ___
These solution are not viable IMO because they still require some work hence very few will use them, they do not support all features, and they come with a big performance hit. Dota 2 on the Mac is like twice slower than on Windows Vulkan at low resolution.
Apple developed Metal to leverage features of their AX GPUs for new iOS application, giving Apple an edge over Android. Metal isn't going to give the Mac any avantage over Windows PC. I Apple excecs think that, they are idiots. I understand why Metal exists for cross-compatibility with iOS and as a framework that Apple can use on macOS, but why Apple doesn't allow other APIs like openGL and Vulkan (as opposed to Microsoft's approach) is beyond me and I hate when they do that. It's anti-consumer.
Apple doesn't want the Shotgun Seat on the Stagecoach. 'They' want to hold the reins... tightly.
That is doomed to fail, because of a single reason: market share. I understand that it might work in certain markets where the Mac is still relevant, like in movie editing. But even for special effects and 3D, the Mac remains anecdotal and I won't be surprised in the efforts to port Octane to Metal do not prove fruitful.
For other markets like anything remotely scientific , devs don't even know that Metal is a thing. That's laughable.
Thanks Apple for having treated pro users like sh*t for the past 10 years and for setting the entry price of their only PCIe Mac at $6000.
[automerge]1590991967[/automerge]
I know that. My point is that this strategy makes no sense for macOS. You can come up with your own API and drop cross-platform ones when your market share is big. Apple can afford this strategy on iOS. But thinking that the success of Metal on iOS will make make this API successful on the Mac is idiotic.
Last edited:
There is a major tight coupling aspect to the increasingly ( now total) Apple implementation GPUs. ( Metal's FP64 'hole' for instance.)
However, that is somewhat in a vacuum of what others were doing. Nvidia, Microsoft, and Google were not 100% behind OpenCL in that time period. Nvidia pulled some "embrace , extended, extinguish" moves on OpenCL to free up more breathing space for CUDA. Microsoft has/had their own compute variant. Google was pushing Renderscript earlier on in Android development.
Similarly "Open GL next" was mired in Kronos committee up until AMD contributed Mantle. If AMD hasn't given them something concrete to converge on they might still be lost in the woods. It wasn't just Apple on the "forked" solutions path.
One of the substantive contributing issues why Apple moved to Metal was time. Didn't have time for the large , slower evolution committees to figure out a "Open" solution which wouldn't be heartily adopted by everyone else .
But Macs do have a "large enough" critical mass. Mac's cross the 100M active deployed mark a while back. Windows was a viable ecosystem when it had 100M users. There is little reason Macs would not be a viable ecosystem with the same number. Throw as iPad Pro subset of iPadOS on top of that 100M and it is all the more a sustainable ecosystem. Some app developers can choose to ignore, but they will be passing up revenue.
Macs coupling to the higher iOS/iPadOS growth will generally help far more than Macs adding a Win32 sidecar to the Mac stack. Macs don't have to "feature match" Windows blow for blow to "win".
MacOS major advantage over Windows has been more stable, more secure (or at least, less attacked) , and more "just works". Apple destabilizing macOS is a bigger flaw than anything they are doing with Metal vs other stuff.
OpenGL has been allowed for a long time on macOS. It is deprecated now, but "allowed" being problematical is a future problem that is probably at least a year or two out. The problem for OpenGL is that standard is mostly going into zombie mode. Apple doesn't deal with zombie mode standards all that well at the forefront of the library ( lower level unix stuff like shells , tty , command line stuff are relatively worked with well but that isn't the core of every basic macOS app either. ). The rush to Apple ARM may be part of the rush to shove OpenGL off the cliff. If so, they yeah that probably won't help the Mac Pro + iMac Pro side of the ecosystem.
OpenCL might get a reprieve on macOS. OpenCL 3.0 is largely a retreat back to OpenCL 1.2 ( which Apple already has so...... so why get rid of it? If the 2.0 parts that Apple didn't like are now far more optional in OpenCL 3.0 they'll just not implement them can still can claim OpenCL 3.0 implementation. I wouldn't be surprised if Apple canceled the OpenCL deprecation at the upcoming WWDC 2020. There may be some narrow aspect(s) of the required core that Apple scoffs at but that is a 'pill' they should just go ahead and swallow. If they don't that will be a blow to some of the more heavily computation focused workloads that already put in OpenCL port work. ). If Apple still walks away from OpenCL with the shift back to 1.2 then it probably isn't as much about Metal or competing with Windows as it is just being cheap ( tossing more coin into the Scrooge McDuck money pit. ). There is a decent chance they'll take that path.
Vulkan ( and Metal and the other similar contemporaries ) are more so aimed at framework developers than at application developers. If a game engine is ported to Metal then all the apps that sit on top of that game engine come relatively easily come along also. Apple's bigger 'fail' with Metal is more so that their sales pitch is more so you should port your OpenGL app calls to Metal "it is easy". The big mismatch is tons of basic apps don't need that kind of low level control. There is a bigger dust up there than in the Vulkan targeting framework layers. The problem with Vulkan and Metal is that have two 'cooks' in an even smaller kitchen. The closer to running on the 'raw iron' you get the more likely going to get into conflicts of "who is in charge" when have multiple users of the same single resource. The metrics where there is a single app at a time that takes over the entire screen aren't the core issue. Nor really the classic normal mode of a modern era Mac ( since move to the Mach based Mac OS X - macOS ).
If the GPU hardware vendors don't pick up the "shared control" work then it probably will be limited in some ways. It isn't so much that Apple has to do the work. They need to have a driver stack API design that allows that work to be passed to the GPU hardware vendors. The catch-22 is that would be a bigger larger driver for the GPU hardware vendors which probably both Apple ( more responsibly pushed out) and vendors ( more work for a limited growth market). Both sides would have less work to do if limited to just Metal ( which isn't going away).
Where Apple more so appears to be missing the boat is a level up from Metal/vulkan at the more common app framework level. There are some gaming applications engines ported to Metal. Lightweight apps are porting on top of HTML ( and hence Webkit) but a big chunk of the stuff in the middle I think is being under served. I think that is far more fragmented than Apple wants to acknowledge.
There are about 1.4 billion deployed installations of Metal.
Apple Now Has 1.4 Billion Active Devices Worldwide
Apple CEO Tim Cook today announced that its active installed base of devices has hit 1.4 billion, a milestone the company hit at the end of December....
www.macrumors.com
Sure, maybe iOS is the market holding Metal up. But that's a gigantic market.
Windows is harder to estimate, but current high estimate around around 1.5 billion active installations. That includes other devices like the Xbox One. The low estimate is 1.2 billion active Windows installations, which would mean there are less DirectX devices than Metal devices.
It's 2020: How many PCs are still running Windows 7?
A hundred million here, a half-billion there: Calculating the installed base of PCs, including those still running Windows 7, is a tricky task, filled with uncertainty. After clearing away the noise, I think I’ve got a reliable estimate.
www.zdnet.com
Statistically, the number of active users with Metal devices and the number of active users with DirectX is nearly even. Metal will be fine. CUDA doesn't come pre-installed on anything, but it's also hard to see how CUDA could ever catch up to Metal in overall deployments.
(This post is just re-emphisizing what deconstruct60 is saying, I'm not disagreeing.)
The total number of Macs isn't much relevant IMO. (The total install base of Metal devices is even less, to reply to goMac's comment). What matters is the Mac market share for a given app that may be ported to Metal, and Apple has made every effort to reduce that market share in the past 10 years (no replacement for the 2010 Mac Pros for three years, then the trash can, then an outrageously priced replacement).
For instance, what percentage of Blender users work on Macs? Blender devs have shown little interest in using Metal. They will go Vulkan.
And if a game engine isn't ported to Metal, we're screwed or have to resort to some translation layer, if that's even an option.
There are open-source programs to translate DX11/12 to Vulkan (DXVK). I'm not aware of anything of the sort for Metal. So DX games are a no-go, while many can run decently on Linux (and Vulkan Windows games like Doom run even better).
Valve has said they're not interested in using DX12 and they did not even mention Metal. and I bet they won't port any of their upcoming games to Metal (VR or not). I'm sure that most game engine developers beside Unity and Epic are not interested either (granted, Epic and Unity are the too main actors).
How does it work on Windows? Microsoft allows DX12 and Vulkan to coexist.
[automerge]1591037017[/automerge]
"maybe", you think?
Where are all the recent AAA games running on Metal? Surely, they must exist since the install base is larger than the directX install base.
Metal already succeeded... in the Apple eco system and that's all that matters for Apple. They don't care about Windows or Linux. Anyone developing for iOS or macOS is already on board.
CDNA will be useful for the Mac Pro. I imagine Apple's custom ASIC designs will be a hybrid solution.
For iOS maybe. For macOS, that is not the case. And many do not develop for macOS to being with. Metal is certainly not going to solve that problem.
So let's say you're asked to develop a brand new application for macOS starting now or soon, what are you going to use?
All the major game engines support Metal.
It's more of a problem of "Where are all the AAA gamers using Macs?" Even though Metal has a larger user base, most AAA gamers don't use Macs.
It's why you see stuff like Frostbite games from EA on iOS but not on Mac. They just don't want to incur the additional costs of testing on Mac for so little return. Even though Frostbite supports Metal, and EA could bring games like Battlefront 2 to the Mac on Metal.
Pro apps and games will continue to be pressured by iPad. But there isn't much demand right now for Battlefront 2 on an iPad.
[automerge]1591045801[/automerge]
The % of code in an app (especially if you're already supporting multiple APIs) that's written in Metal or OpenGL or Vulkan or DirectX or whatever is usually only a few percent. It's an important few percent, but it's not really going to block anything as long as there is interest.
Plus if you are writing for Windows, you're probably using DirectX, and I don't think anyone has proposed Apple add DirectX to macOS. If a development house is really insistent on relying directly on the Windows platform there isn't much Apple can do to fix that.
Last edited:
This is an edge case. How many brand new apps are developed primarily for macOS and could take advantage of Metal, beside the usual Pixelmator and Seriff apps?
I'm talking about big cross-platform apps. From devs that could survive without the Mac and are getting increasingly pissed to have to change their codebase at every whim from Apple.
[automerge]1591051190[/automerge]
Allowing Vulkan on the platform would be a first step. At least DXVK would work on macOS and we'd have a few native Vulkan apps.
Vulkan is on the platform. It's just third party libraries not maintained by Apple. Which is exactly the same as it is on Windows. Vulkan doesn't ship with Windows and Microsoft doesn't maintain it.
GitHub - KhronosGroup/MoltenVK: MoltenVK is a Vulkan Portability implementation. It layers a subset of the high-performance, industry-standard Vulkan graphics and compute API over Apple's Metal graphics framework, enabling Vulkan applications to run
MoltenVK is a Vulkan Portability implementation. It layers a subset of the high-performance, industry-standard Vulkan graphics and compute API over Apple's Metal graphics framework, enabling Vu...
github.com
There are also a lot of commercial DX -> Metal libraries available.
I know that, but at least native Vulkan is allowed on Windows. On macOS it's not, because Apple does not provide the kernel interface to implement graphics APIs.
And I know about MoltenVK. It's not native Vulkan.
[automerge]1591082463[/automerge]
Such as?
It's Vulkan by the Kronos group, the official group in charge of Vulkan. Missing features are an issue, but I'm not sure I see much point beyond that in "native" Vulkan. It's a completely valid way to do Vulkan, and Windows also uses a Vulkan to DirectX layer in cases where third party graphics stacks aren't allowed on Windows.
I dunno, they're all commercial. How do you think games, Parallels, and VMWare turn DirectX calls into Metal calls?
MoltenVK is Vulkan on top of Metal. It's like saying that DirectX is supported on the Mac thanks to Parallel or Wine. The fact remains that the level of support of Vulkan on macOS is far behind what's on other PC OSes. There is no Vulkan driver. Go to the Vulkan presentation page and see that kronos considers macOS and iOS as "not served by Vulkan".
Honestly, I don't know where this is going and why you try to defend apple here.
As for "Vulkan to DirectX layer" on Windows, I don't know about that. Vulkan games run natively on Windows with awesome performance and there are Vulkan drivers you can install. On the Mac, you get a clear performance hit through moltenVK, assuming it supports the required features.
And those DX to Metal translation layers are kind of locked to some virtualisation software. I'm not even sure VMWare supports DX11 yet. It'd be nice of we had something like DXVK for Metal. I'm not sure why no one has produced one yet. Fear of legal issues with MS ?
Feral and Aspyr seem to have some translation libraries for their ports that's more direct than virtualisation. I don't know the specifics of how they do it or how large a subset of DX9, 10, 11, (12?) they have translations for and how specifically their workflow is, but I know they have something. If you look at the game files for one of their titles there will be the directX files as well as a library file that I can't remember the exact name of but something like feralDX something or other. At least in a few of the games I've looked into.
As jeanplain says, it's not really the same thing as having direct Vulkan support. It's great that it's there and it's absolutely better to have MoltenVK than nothing, though if I'm not mistaken it's real time or JIT runtime translation where it would be really sweet if it could do compile time Vulkan -> Metal translation and bypass performance penalties. - In any case it's just not the same as having the GPU driver directly pick up Vulkan API calls. Writing a German article and putting it through Google Translate is not the same as being able to write English in the first place. It may do the job well enough that the article is understood, but it's not the same
Feral appears to have some very good translation tool, but it still requires months of work to port a game. Granted, they take the time to do it right.
DXVK allows running windows games on Linux with relative ease. From what I've heard, proton works pretty well.
Even "native" Vulkan is JIT shaders, which is why "native" Vulkan as some necessary thing is kind of eh.
I don't know if MoltenVK supports it, but you could even pre-compile the shaders to Metal's shader packaging. But again, any GPU shader language is going to involve JIT. Even pure Metal would require JIT.
Even "not shader" code still has to be passed through a driver layer and translated to GPU calls. So running Vulkan calls through Metal is really not a big deal, especially because Metal is so low overhead. Metal is just acting like the driver layer you'd see in a "native" Vulkan implementation.
[automerge]1591204127[/automerge]
Valve had DXVK/Proton running on the Mac. They discontinued it due to lack of interest. It was running on top of Metal.
Remove macOS support · ValveSoftware/Proton@a841204
Compatibility tool for Steam Play based on Wine and additional components - Remove macOS support · ValveSoftware/Proton@a841204
github.com
Last edited:
Indeed. It's by no means automatic, but the graphics API calls are also only part of the code, and Wine in general, in my experience, works better on Linux.
Right yeah it's all JIT to varying degrees, yes. But what I meant was an additional layer of work to be done at runtime. How big the impact is is hard to say since we can't really measure the difference between just Vulkan and MoltenVK. Though I suppose it is possible to write a test with Metal vs equivalent Vulkan code through MoltenVK and measure that.
To my knowledge you can't pre-compile your MoltenVK shaders into Metal; It can only happen at runtime, but I could be wrong which would be cool.
I think this is making a big deal out of something that probably isn't a big deal. The driver layer is going to be much heavier than something like MoltenVK. "Native" Vulkan isn't talking directly to the GPU. There are still a lot of layers of software and drivers and kernel time and JIT compilers for it to go through.
Something like DXVK can be faster than "native" DirectX, and it's a translation layer. Again, I think the "native" Vulkan hand wringing probably isn't important. OpenGL on iOS is now a translation layer to Metal and no one even noticed, I think performance even improved.
I don't know if that's how MoltenVK works. But it's completely possible to compile Vulkan to Metal bitcode, and save a bit of work at runtime. Metal bitcode still has to be JIT compiled to AMD/Intel/Nvidia Bitcode, or course. So you're not eliminate JIT work.
That said, runtime hit we're talking about is extremely minimal and is one time.
Edit: MoltenVK does mention in their docs that shader conversation can be done at build time instead of compile time.
Last edited: