> C. Metal is a high-level language, Vulkan is low-level. Apple wants you to use a high-level language so they have more flexibility in optimizing the low-level for you now and in the future, which Vulkan closes off more.
The problem is that historically, this is what's lead to tons of issues in games. Drivers make their own "optimizations" resulting in terrible performance for some task on one GPU, and great performance on another. Or instead of performance differences, it's outright bugs.
Then, combine that with GPUs being fairly expensive, and fast moving when it comes to new features. Most game studios aren't going to buy 20 different GPUs and test their entire game on all of them. So games often ship with terrible performance or bugs on various different GPUs. And it's often not the game's fault: are games really supposed to detect your exact GPU model, and change code paths to work around a driver bug? That's crazy.
To combat this, GPU drivers often get updates after a game launch that fix the issues with performance/bugs for specific games at the driver level, when it detects that those games are running. So now drivers become a pile of game-specific hacks, making the problem even worse.
This is the reason Vulkan is so low level. The goal is to make sure drivers don't get horribly bloated, and games aren't working around driver-specific bugs (they still happen, just hopefully less). And when games want to use specific GPU features for extra performance, instead of drivers trying to magically improve normal operations, they can make a vendor-specific extension providing the new functionality that games can opt into when the feature is detected (e.g., raytracing). That's part of why Vulkan has so many more extensions than OpenGL does.
Vulkan may be low level, but it's intended to be so. By foregoing Vulkan support, Apple rejected any attempt at making a higher level API on top of Vulkan that would work on every system. Instead, WebGPU has to try and abstract over Vulkan/Metal/DirectX12 separately, which mostly works, but leads to a whole lot of clunk and longer development time than if Vulkan was the standard everywhere.
That's not to say macOS should never have made Metal. But by not adding Vulkan support in addition later on, they're really hurting cross-platform compatibility. Sure, now Apple can optimize their platform to the best of their ability (theoretically). But that comes at a huge overall cost to the ecosystem, for instance with games having poor support for macOS.
> Then, combine that with GPUs being fairly expensive, and fast moving when it comes to new features. Most game studios aren't going to buy 20 different GPUs and test their entire game on all of them.
This is mostly irrelevant for MacOS/iOS/iPadOS/tvOS. The number of people plugging in an external GPU on Macs is minuscule
> for instance with games having poor support for macOS.
Games don't have poor support on MacOS because of lack of Vulkan. They have poor support because pretty much no Mac (except maybe the newest M1 macs?) have gamer level GPUs and no market for high end games. Gamers basically know if you want to game, get a PC, and game devs know not to waste money on Mac ports.
> Games don't have poor support on MacOS because of lack of Vulkan. They have poor support because pretty much no Mac (except maybe the newest M1 macs?) have gamer level GPUs and no market for high end games.
It is basically this:
Gamers don't buy Macs (at least not as their only system, or their primary one for gaming) because there are few games.
Few gamers buying Macs exclusively means there is little unique Mac demand for games (that is, demand that can't be tapped on another platform, because the potential buyer has it and will buy games on it).
Little unique Mac demand for games means few games, and thus the cycle is closed.
Breaking out of that is hard, and Apple would probably need to be the one to expend the effort, and Apple doesn't seem to want to do that.
Breaking out of that might be significantly easier if Apple entered the console space, which is something I sort of assumed they would eventually do. I'm not particularly clued in, though.. does anyone have a good reason why they haven't?
Because game developers despise Apple. The only major devs who gave a damn about Mac support was Blizzard, and even then they didn't really care about porting anything other than World of Warcraft to Apple Silicon (or even Mac altogether). Valve tried extending an olive branch a few years ago with Steam Proton support on Mac, but Apple batted it away, and Valve responded by pulling SteamVR support for Mac. The rest of the AAA gaming space absolutely will not care until Vulkan is natively supported on Apple hardware, because there's no way they're going to put their games on it otherwise. Without Vulkan, you're not just missing out on Vulkan titles (of which there are many), but also DirectX ones that would be playable at near-native framerates through translation tech like DXVK. The fact that Apple doesn't have a robust, high-performance graphics API is completely gimping their chances at getting game developers to care, which is why completely broken platforms like Linux and BSD somehow have better game support on hardware that's a fraction of the price.
Oh, and there's the fact that the console space is a low-margin industry where their competitors are taking a loss on their product. The PS5 and both new Xboxes are being sold below-cost just to move units, with the expectation that users will pay for digital purchases/subscriptions to compensate. The Nintendo Switch is barely staying underneath $300, to the point that it normally sells at a loss during the holidays just because of shipping prices. Apple is known to drive massive hardware margins, so making a product that's actually worth it's value isn't all that attractive to them. They'd rather have their cake and eat it too, which has worked pretty good for their insane 30% margin they cut off nearly every microtransaction they see. The less attention they draw to that fact, the better.
Apple do have a robust high-performance API, Metal. Arguably it has the best ergonomics of any of the low-level graphics APIs. All relevant game engines already have Metal support, too. There's even an equivalent to DXVK in MoltenVK. It's not that different from Microsoft's position.
It's possible Apple might make an M1 Apple TV with a decent GPU. Like the Macbook Air, it's likely it'd be cheaper to manufacture than competitors with similar performance. I suppose we'll see.
> Apple do have a robust high-performance API, Metal.
Metal is neither robust, or, arguably, high-performance when compared to DirectX or Vulkan.
> Arguably it has the best ergonomics of any of the low-level graphics APIs.
It's not a low-level API. By Apple's own admission, Metal is hopelessly high-level and can only achieve the ergonomics it has by abstracting away all the features that gamedevs care about and putting the keys to the kingdom in Apple's hands.
> All relevant game engines already have Metal support, too.
I like how you qualify this with "relevant", as if I'd come up with a list of all the engines without Metal support and you'd wave them away as irrelevant since they don't support Metal. Plus, Metal isn't just a compilation target. A "port" to Apple Silicon doesn't entail checking off a new box on the compiler, it's a long and arduous process of porting shaders, bytecode, 32-bit libraries, x86-based libraries, API calls and more. Since Apple provides game developers no incentive to do that work, they continue to refuse porting to their system.
> There's even an equivalent to DXVK in MoltenVK. It's not that different from Microsoft's position.
Yeah, except the main difference is that DXVK gets near-native performance, while MoltenVK is far too slow to be considered for regular use. Do you honestly think a Proton-like compatibility layer could be built on a technology that needs to translate Vulkan code into a higher-level, slower API? Keep dreaming.
> It's possible Apple might make an M1 Apple TV with a decent GPU. Like the Macbook Air, it's likely it'd be cheaper to manufacture than competitors with similar performance. I suppose we'll see.
Comedy-freaking-gold right here. Let's say that you're right, and Apple does release an Apple TV with an M1 processor in it. I'm going to give you an insane benefit of the doubt, and we'll assume that they cut down the price to $500 (using the Mac Mini as a starting point). At peak performance, the M1 can churn through a measly 2.4 teraflops. There are last-gen consoles that were faster than that, not even to compare them to the 11 teraflops that the Xbox Series X and Playstation 5 pump out. Okay, so let's put a faster GPU in there: the M1 has 8 GPU cores, so getting it to be as embarrassingly parallel as it's peers would require us to multiply it's core count by 4 or 5 factors. That would require a whopping 32 GPU cores, the same amount that the $2500+ Macbook Pros carry. If they did make a $500 console of that ilk, they'd be losing money on every unit shipped for the GPU alone.
I genuinely have no idea where you're getting any of this stuff. Maybe read up on game development before responding?
You exaggerate Metal's level of abstraction. It's still far lower level than OpenGL or D3D9 and allows most modern optimisations. It's supported by all popular game engines, same as with D3D12 and Vulkan. Of course there are plenty of niche ones that don't, but that's also the case for Vulkan.
In practice, games (usually through engines) overwhelmingly target the native graphics APIs. D3D12 on Windows and Xbox, GNM on PS5, Metal on iOS/macOS/tvOS, NVN on Switch, etc. In practice it doesn't matter much.
MoltenVK is not as good as DXVK right now, sure. That still has nothing to do with either Apple or Microsoft. They both offer exactly as much support.
The chips in MacBook Pros aren't the bulk of the cost. I think it's unlikely Apple would make a console, but still possible. They have all of the necessary ingredients already vertically integrated.
1. Apple requires Hardware Margins, I am not even aware of a single hardware category they sold that have low / zero margin.
2. Apple constantly pushes changes in their OS and API. Breaking backward compatibility. Part of the reason why many iOS Games dont work after a few iOS update anymore. Compared to console where games are expected to work during the life span of the console.
3. Thirdly and most importantly. There are zero gamers DNA in Apple. They dont understand Gaming.
> Games don't have poor support on MacOS because of lack of Vulkan.
Proton/Wine/DXVK. Wine works on Mac but DXVK barely does through MoltenVK. The lack of proper Vulkan support is directly why games have poor support on MacOS. I'm almost positive if Mac OS had Vulkan support Valve would be supporting Proton on Mac OS.
MacOS had great game support for a while, but axing 32-bit libraries and refusing to adopt Vulkan led big players like Valve to drop support for MacOS in many of their programs. For a short while with Mojave, you could reliably play 80% of the PC games on Steam though.
I had many 32-bits games in macOS but they were all axed, including big titles like Diablo 2 (not the resurrected one), Warcraft 3, and a lot of indie games. This made me realize why no sensible game companies would develop in Apple platforms, unless the games generate revenue continuously (which are mostly pay-to-win games)
A) Many games don't use these engines. The trend has actually been going in the direction of less custom engines, but a significant amount of games still do.
B) Games might not have to deal with macOS if they're using an engine, but the engine themselves still do. This limits what engines can do to the least common denominator. And we all know Apple isn't the fastest when it comes to new standards or features. In the graphics world, that comes in the form of DirectX12 vendor-specific extensions, with Vulkan vendor-specific extensions a few months later, and then Metal support whenever Apple feels like copying it.
Someone else in this thread linked an example about Metal lacking support for a type of atomic primitive that prevented the decoupled loopback algorithm from running on Metal. That means the author couldn't use WebGPU to implement the algorithm, and had to make an implementation in Vulkan and Metal separately (iirc all the details of this correctly, you get the general idea). And it _wasn't_ clear that they couldn't use WebGPU to begin with. The WebGPU spec had to actually be clarified based on the author's investigation. Engines and other APIs wouldn't have to deal with this if Apple just supported Vulkan.
But then we're back to the various pros and cons of Metal and Vulkan. A counterpoint would be that yes, it lacks the atomic primitive, but Vulkan's low-level design means that games would be less optimized for future devices if their developers stopped supporting them.
An example of this would be how Metal runs on AMD GPUs, Intel iGPUs, and now Apple GPUs. Would a Vulkan-based implementation that was originally written for AMD GPUs be as optimized for Apple GPUs as a Metal implementation would have been? What about 5 years from now?
My point is that there are minute details that are benefits and drawbacks to both, and the decoupled loopback would be one of them. I wouldn't be surprised if there are algorithms Metal can do but Vulkan can't.
My point isn't to talk about the various tradeoffs between Metal and Vulkan. Ignore that Metal exists for now. My point is that by not supporting Vulkan, Apple isn't supporting the lowest common-denominator API that everyone else supports. So that leads to people having to make a Vulkan implementation, and then also a Metal implementation if they want to support macOS. Regardless of the benefits and drawbacks of each, there isn't a way to support every platform with one API. And Apple causes a lot of strife because of that.
I don't have a problem with Windows having DirectX12 in addition to Vulkan. Or even that vendors typically add new features to DirectX12 first, with Vulkan getting them later. This is because you can still write a Vulkan program, and have it run on Windows. Apple only supporting Metal breaks "write once, run on any platform". It's one thing for Apple to have Metal as a better supported/approved API that they can make the best apps with. It's another to lack Vulkan support altogether. Because Apple aren't just trying to get the highest Metal adoption. They could easily do that with AppStore restrictions or something, or just accepting that UIKit using Metal is good enough adoption. Lack of Vulkan has knock on effects on every other platform, because now engines have to do a ton more work, and likely have more bugs.
This isn't actually accurate because, if you are a game engine, you can't just have a Vulkan-only implementation. There's plenty of old computers that don't support Vulkan. PlayStation doesn't support Vulkan - better use GNM, GNMX, and PSSL. Xbox only uses DirectX, which has both high and low-level variants, no Vulkan there. iOS is Metal only again. You could use Vulkan on the Nintendo Switch, but NVN is faster and the preferred method.
You might get away with just Vulkan if you were targeting only Windows, Linux, and Android on hardware that isn't more than roughly 5-6 years old. But Linux is a small percentage and they've got Proton, so as long as you don't want to port to Android and not iOS for some reason, why not use DirectX?
"lowest common-denominator API that everyone else supports" - Outside of the PC, Vulkan isn't really that broadly-supported. Yes, you've got Android and Nintendo Switch, but those are only individual items in their respective categories and don't make sense to support alone without the rest of their categories (smartphones and consoles).
> My point is that by not supporting Vulkan, Apple isn't supporting the lowest common-denominator API that everyone else supports
> I don't have a problem with Windows having DirectX12 in addition to Vulkan
Did I miss that Microsoft is supporting Vulkan? I googled, but couldn’t find that. Vulkan and Microsoft both seem to support HLSL, but that’s it, as far as I can tell. What do I miss?
Many game developers don't use any of these engines, and even when using an engine, the underlying graphics API can certainly matter. There's nothing saying that Unreal for example, has to support all the same rendering features in Vk and Dx and Metal. And even the same feature can look subtly different between different interfaces.
The problem is that historically, this is what's lead to tons of issues in games. Drivers make their own "optimizations" resulting in terrible performance for some task on one GPU, and great performance on another. Or instead of performance differences, it's outright bugs.
Then, combine that with GPUs being fairly expensive, and fast moving when it comes to new features. Most game studios aren't going to buy 20 different GPUs and test their entire game on all of them. So games often ship with terrible performance or bugs on various different GPUs. And it's often not the game's fault: are games really supposed to detect your exact GPU model, and change code paths to work around a driver bug? That's crazy.
To combat this, GPU drivers often get updates after a game launch that fix the issues with performance/bugs for specific games at the driver level, when it detects that those games are running. So now drivers become a pile of game-specific hacks, making the problem even worse.
This is the reason Vulkan is so low level. The goal is to make sure drivers don't get horribly bloated, and games aren't working around driver-specific bugs (they still happen, just hopefully less). And when games want to use specific GPU features for extra performance, instead of drivers trying to magically improve normal operations, they can make a vendor-specific extension providing the new functionality that games can opt into when the feature is detected (e.g., raytracing). That's part of why Vulkan has so many more extensions than OpenGL does.
Vulkan may be low level, but it's intended to be so. By foregoing Vulkan support, Apple rejected any attempt at making a higher level API on top of Vulkan that would work on every system. Instead, WebGPU has to try and abstract over Vulkan/Metal/DirectX12 separately, which mostly works, but leads to a whole lot of clunk and longer development time than if Vulkan was the standard everywhere.
That's not to say macOS should never have made Metal. But by not adding Vulkan support in addition later on, they're really hurting cross-platform compatibility. Sure, now Apple can optimize their platform to the best of their ability (theoretically). But that comes at a huge overall cost to the ecosystem, for instance with games having poor support for macOS.