Hacker News Reader

Comment by gjsman-1000 | Hacker News Reader

"But that comes at a huge overall cost to the ecosystem, for instance with games having poor support for macOS."

I don't know if I had this point edited in when you wrote this, but see point F:

"F. Game engines actually support Metal - Unity, Unreal, LWJGL, the most common engines run on Metal fine. Don't use Metal as a scapegoat."

View on HN

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.

Reply on news.ycombinator.com