But MoltenVK will still get better performance than OpenGL on OSX, won’t it? Apple has always been behind the times when it comes to OpenGL performance. They are still using OpenGL 4.1. Apple really wants Metal to be the default API across iOS and OSX, I can see why they are not giving any support to Vulkan and kind of crippling performance with MoltenVK.
Most likely, yes. If not immediately, then definitely in the future.
OpenGL on Mac has been horribly out of date for about a decade or more at this point… and core counts are only going one way.
Apple will do what Apple does. MoltenVK will be a “good enough” bridge for non-native stuff. And i very much suspect it will end up a lot faster than OpenGL was on the Mac.
If you’re a Mac person then there will be short term pain, but long term this is a much better deal than the ancient versions of openGL the mac has had. It will force the issue for app developers to get off OpenGL (which on the mac - sucks, but it is easy to port to) and to re-write in either Metal for native performance or if they’re cross platform - Vulkan via MoltenVK.
Win for apple performance and probably win for the application’s performance everywhere else too. Mac forcing the application to switch to Vulkan (if it is a cross platform app) will mean you’ll likely have the option to run it under Vulkan in either Windows or Linux too - which will also improve its performance there.
People should be cheering for this to happen IMHO. Short term pain, definitely. Long term, win win…
Even if an application gets re-written for Metal, as i understand it all of DX12, Metal and Vulkan are somewhat similar and easy to translate between because they give you more direct access to the hardware - which is the same across platforms.
Well, who’s fault is it that macs are running old versions in the first place?
Again, this is not about improvements, this is about shutting doors.
Says you. Perhaps apple decided not to bother wasting time improving their openGL support when they planned to replace it.
The work on metal would have started several years ago (apple didn’t just conjure it out of thin air), likely around the time AMD was playing with Mantle. Before Vulkan was a thing.
There’s a shim, get over it.
Does that change the fact that apple kicks out an open standard for a closed one?
Yes, because they want people to write code that runs faster?
Apple deprecate things. This isn’t news. If Vulkan was a thing before Apple started work on Metal, maybe they would have adopted it. But i very much suspect it wasn’t. So they didn’t.
They adopt open standards where possible, they contribute plenty to open source. The open standard solution at the time did not exist.
If you want something to whinge about, the next version of macOS has deprecated 32 bit x86 support entirely…
Again though, short term pain, long term gain.
edit:
And again, if this encourages people to stop writing for openGL and to consider their options and select vulkan via moltenVK shim for metal and native elsewhere, this is a win for everyone.
No. … No it does not.
That is what you call a rhetorical question.
Apple is kicking out an open standard for a closed one.
And i gave you their motivation for doing it.
If you don’t agree - fine. You aren’t a mac user anyway? Why do you care?
I gave you example of how this will likely be positive for everyone even if (and especially if) you aren’t a mac user - because it will be the kick in the pants application developers need to get off openGL and onto something modern. like vulkan.
even if they go to metal on the mac natively, metal, vulkan and DX12 are a lot more similar to each other than DX11 and openGL as i understand it.
the optimisation methods will be more likely to cross-over due to the APIs having similar goals and implementation.
It’s worth noting that Apple were the original creators of OpenCL. They are not completely hostile to open standards.
I personally find OpenGL to be a somewhat cumbersome abstraction level. You really want to be either lower level (as OpenGL has gradually trended toward, and DX, Vulkan and Metal have embraced) or higher level (as the proliferation of high level UI and game and video and compute etc etc engines shows).
I think moving the focus to good abstractions over lower level platform-specific interfaces is going to ultimately lead to better software. There will be some developers and packages who aren’t able to adapt being left in the dust, for sure. Apple are frequently the ones to push progress, even if it’s inconvenient.
Cause I do. Why shouldn’t I?
Also I am a computer user, that includes macs.
I am writing this on a macbook pro.
And I still have a mac pro running 10.13 and a bunch of photo editing software.
And a lot of that is still running on openCL and openGL.
I simply don’t believe that the existence of a closed source thing is beneficial for open standards. Do you know of examples for that?
People Apple really really needed founds to make new emojis, a decent iOS release that doesen’t crap out because of ASCII characters and pay governments to avoid the spread of the “right to repair”. I don’t think is right to complain about Apple’s choices. Also they give Pro users what they wanted, right? A black iMac that melts of itself on sustained load, has a “Pro” in the name and nobody at Apple knows how to fix it.
Jokes aside I think Apple wants to compete on the same level as Microsoft but forcing users of the new OS and new machines (already updated) to use that API. I don’t think is the right move leverage the owning of an entire platform to force the possible use of a new API. A good move to me is show the strenght and power of what your approach is capable of. But I think they can’t do that because they don’t make any of the core components in their laptops and desktops. I can’t wait to see how this thing will screw the manufacturer that will have to do a lot more work to take openGL and openCL out of their drivers.
I don’t think anyone else had mentioned it yet, but there is a similarity to their adoption of Lightning on phones.
Apple builds their own solution Metal/Lightning that is very similar to the cross-platform standard, Vulkan/USB-type-C.
TCP/IP - if it wasn’t supported in closed source windows it would not have taken off
HTTP - if it wasn’t supported in closed source server software, it would not have taken off
HTML
TLS…
IPSEC…
zeroconf…
XML…
there’s a number of examples…
OK, let me rephrase my question so you get my point:
How does an open standard like Vulkan benefit from the existence of a competing closed standard like Metal?
See, your example is pretty much the opposite of what apple is doing.
I wonder, if MoltenVK didn’t exist, or at least was not officially supported by Khronos, would Apple have given in and made official drivers for Vulkan?
It will be interesting/worrying to see how many applications will be written directly for D3D12, Metal, and GNM.
Low Level GPU API Support
Xbox One | Windows | PS4 | Switch | Linux, BSD, etc. | OSX | iOS | |
---|---|---|---|---|---|---|---|
Vulkan | Native | Native | Native | MoltenVK | MoltenVK | ||
D3D12 | Native | Native | |||||
Metal | Native | Native | |||||
GNM | Native | ||||||
NVN | Native |
Does anyone know for certain if PS4 or Xbox do not support Vulkan?
Sources
Dota 2 Vulkan Performance Across MacOS, Windows 10 & Linux Benchmarks (using MoltenVK on OSX)
PS4 Presentation (graphics on slide 32)
Considering that Vulkan can be used on top of Metal, it’s kinda hard to argue that more people won’t end up using Vulkan than if Metal didn’t exist.
TCP/IP originated outside of Windows, and in fact the original implementation of TCP/IP was in BSD. That’s where TCP/IP really caught on. Eventually Microsoft used the BSD network stack in Windows, because the BSD sockets API and TCP/IP stack were the gold standard for networking at the time.
The argument is that in the absence of the Metal API, Apple would be forced to add support for Vulkan.
That’s not a very strong argument, it’s more of an assumption.
I would argue that it is often the case that an existing closed standard is the impetus of open alternatives. Take for example proprietary Unix, which inspired the creation of both GNU and Linux. How about CUDA, which prompted Apple to introduce an alternative open standard, OpenCL? What about G-Sync vs FreeSync? The mechanism for FreeSync already existed but had very little attention until G-Sync came out.
Don’t know if apple would have gone vulkan if MoltenVK didn’t exist. But it’s kind of irrelevant. Metal does exist, and existed before Vulkan.
Fact is, they released Metal before Vulkan was even a thing. Apple saw a need, built their own thing and that was that.
So bitching and moaning that they didn’t use Vulkan… well. It wasn’t an option when Apple decided they needed something. DirectX wasn’t an option either. There was no open or closed alternative to fill the need so they built something themselves.
And now, there’s a shim. So you can use Vulkan if you like, anyway.
So i’m not quite sure what the problem is, other than people desperately looking for a reason to be angry.
You’re already going to have to use a bunch of proprietary APIs to code for the Mac in any case.
Dropping openGL is another issue. However - someone can write an openGL shim (openGL equivalent of MoltenVK to translate into metal) which it shouldn’t be a huge problem if required, because openGL is an open standard and metal is well documented.
But really. Its time to get off openGL for performance reasons, or competitors who do so will eat your lunch. Deprecating OpenGL is apple’s kick in the pants to encourage that.
Letting app developers be lazy and continue with openGL (because they can’t be bothered updating their code), when on windows they’re going to be using DX12 or Vulkan for improved performance is just going to put the application performance on Mac further behind.
This forces the issue. The developer either re-writes for Metal, MoltenVK, or the niche they filled is open to someone else writing a native Apple application.
You may not agree with that strategy, but this is Apple’s strategy for ensuring that crufty old application software isn’t carried forward. Similar to the way they deprecated Rosetta pretty quick to drop non-native applications with Lion.