Hacker News Reader

Comment by dagmx | Hacker News Reader

Vulkan would likely not really have helped macOS gaming in any form. I consider it a red herring that people point to.

The number of games that run natively on Vulkan is negligible. The number of games that run on Metal by comparison (natively) is orders of magnitude higher.

If we're ONLY talking about the ability to use Proton, Apple does now have Game Porting Toolkit that does effectively the same thing with comparable performance characteristics if you take out the other contributing overhead elements.

View on HN

Vulkan probably wouldn't help macOS gaming from a users' point of view, but it sure would be nice for us engine developers. There aren't many Vulkan games, but the big 3 non-in-house game engines (Unreal, Unity, Godot) are all committed to supporting Vulkan in addition to Metal, so we (collectively, the engine dev community) currently have to support both. Dropping Metal would reduce the amount of engineer time spent chasing down Metal-specific bugs (which is not inconsequential), which allows us to spend more time on actually interesting features that users want.

Metal is a hidden tax that isn't obvious, but it's there.

Interesting point of view that could also be the other way around, Vulkan support being a hidden tax for the love of open source and free software rather than something really useful the market needed on top of others APIs / GPU architectures / platforms, pushed by a subset / minority of developers more ideological than practical grounded developers who accept that competition of private standards will bring out the best user experience, each platform having its customized architecture.

After all, scientists don’t write much CUDA oriented for game development anymore or custom maths shaders, they have their own CUDA libraries helping them in their own domains better than what a gamedev orienter Vulkan would do. Any percent shaved off developer time and running time is worth a lot of money.

The Apple Metal platform surely is customized to the needs of Apple, its devices and its users ultimate needs, in a way Vulkan will never be. Unified memory on recent Apple silicon M1 M2 M3 where RAM and VRAM are somehow merged.

Maybe the society of worldwide developers had better things to do than spend precious time on Vulkan.

Coverage. Metal only covers Apple. Vulkan covers so much more.

But money talks and game engines want a slice of that sweet apple pie.

> Metal only covers Apple. Vulkan covers so much more.

I'm not sure "more" is the right term here. There are about 1.3 billion iPhone users worldwide. Sure, Vulkan covers more OS environments, but how important is that to a game developer vs. total available users? Does Vulkan user reach exceed 1.3 billion?

How many iphone users will pay 60 dollars for a game, like you can try and achieve on Steam or Switch? I feel like the iOS game market is pretty different.

More money is spent/made made on iOS gaming than on traditional PC gaming, even if the $60 up front model isn't something iOS users are willing to accept. I almost think they're right to tolerate mtx models btw. At least if games are f2p, companies aren't releasing them broken/unfinished.

Can't release unfinished/broken games, when what they're releasing are not games at all.

OS coverage vs pure numbers is something for the game developer to be worried about, and by extension the game engine devs.

You want to get into the iOS gaming market, go Metal. By definition you've expressed you don't care about the other OS's.

You want to make a AAA game, you probably don't go Metal if you want enough market coverage to recoup your costs - though I will be delighted to be proven wrong when a AAA iPhone game comes.

If Apple want to change their "AAA game" attractiveness they need to address this. It's not that hard - the article took a month but even a year is fine. Apple just needs to get it done, but it doesn't seem like they care to make User<->GameDev relationship easy. Either the gamedev needs a whole other version of their game on Metal. Or the users have to do a lot of homework and fiddling to get a modern AAA game to run.

I wonder if they have Vulkan internally and simply know their GPU won't look good in direct comparisons - which is fair; beating or even leveling with nVidia is hard. But if anyone can show AMD and Intel how to do it....

AAA don't care about Vulkan, they care about Apple, Sony, Nintendo and Microsoft proprietary APIs.

minor nitpick: did care when Google Stadia was in the list. But it did not worked out and everyone took a big L on that and now Vulkan support has been mostly purged already.

The reason why Stadia is no more, is exactly because they don't care.

Google was starting to offer a DirectX porting kit on the same year they decided to ramp down Stadia, there is even a GDC talk on it.

My opinion on the facts I saw don't agree with your interpretation. No one here on HN cares about it =) so I just drop it.

My hot take is that when AAA games will be shipped on mac os they will not use porting kit in runtime and just call Metal. Imho API court battles are fun to watch from afar.

> You want to make a AAA game, you probably don't go Metal if you want enough market coverage to recoup your costs

Likewise you don't care about Vulkan. You care about DirectX and whatever Playstation has

> You care about DirectX

...exactly. Which is why, unless you're given a license to re-impliment DirectX, it makes so much more sense to use Vulkan and it's DX9 through DX12 translation layer.

What am I missing here?

You're missing that people don't care about Vulkan at all: https://carette.xyz/posts/state_of_vulkan_2024/

And the translation layer exists largely due to Valve business decisions, not because "community came together or something". This glorious amazing support didn't even really exist until 2018 (when it was launched with official support of 27 games)

1. Apple has never truly cared about gaming on the Mac

2. iOS only supports Metal, and Metal serves Apple extremely well

3. Apple's dropping of 32-bit apps and switching to M* chips has hurt gaming on Macs much more than any perceived harm from not supporting Vulkan.

Surely there are more Android users than iPhone users worldwide, and if you target Android you target Vulkan.

Only if we don't care about those using devices where OpenGL ES is still more stable, with less buggy drivers.

If you only care about latest Android versions, and Samsung and Google phones, sure go Vulkan.

My brother in Christ, OpenGL ES is officially depreciated on all Apple platforms. It is not "more stable, with less buggy drivers", I've used it.

I thought we are talking about Android, and which APIs makes business sense, when AAA actually want to get paid, instead of having to pay back store returns.

I thought we were talking about capable APIs for creating enjoyable experiences, not barebones rendering frameworks for building flashier online casinos. My mistake.

Depends if those enjoyable experiences pay the mortgages of the developers.

It feels unlikely. Much smaller companies (Broadcom, Qualcomm) have no trouble writing compliant Vulkan drivers (let alone singular people), so I find it hard to give Apple the pass here. Assuming good faith on their part, Vulkan should be available; or at least some kind of cross-platform API target. Otherwise people are just going to ignore Mac and keep focusing on DirectX, like the status quo.

Vulkan is everyone's ticket out of that mess. Not only does it provide Apple an industry-standard API for third-parties to develop on, it flips the DirectX problem on it's head. Because you support Vulkan 1.3 you get DXVK support alongside DX9, DX11 and DX12 support. Now it doesn't matter what third parties do, because you win every time; Steam Deck politics.

The status-quo is simply detracting from the value of using MacOS; the only feasible explanation is that Apple is hoping to somehow force developers into using Metal natively. Outside Tomb Raider and Resident Evil, I just don't see it happening.

> The Apple Metal platform surely is customized to the needs of Apple

That clearly doesn't stop anyone from writing Vulkan drivers for the hardware, though. OP appears to be blatant evidence of this.

For example; CUDA is well-customized to Nvidia's specific hardware, but their hardware also supports Vulkan drivers. Same goes for Intel with oneAPI and AMD's ROCm; all of them still support Vulkan. Apple is quite literally one of the only mainstream manufacturers that does not support it.

Your example of taking games that dare go the full Metal route makes me wonder : to which projects was adding 100% native Vulkan compatibility / support worth the resources spent on this and not something else ? What’s the full Vulkan platform having a dedicated OS running solely Vulkan with a Vulkan based GPU and for which real life uses ?

> What’s the full Vulkan platform having a dedicated OS running solely Vulkan with a Vulkan based GPU and for which real life uses ?

Steam Deck handles it just fine, alongside OpenGL. You use Vulkan to run DirectX games, OpenGL to accelerate the desktop and browser (can soon be replaced with Vulkan too) and fall back to OpenGL for everything else. I'm not aware of any desktop stuff the Steam Deck can't do; it edits video, it runs Blender, it can browse the web and compile apps.

Granted, Vulkan of course isn't a panacea here. But without it, stuff like the Steam Deck simply wouldn't exist. Vulkan is valuable because it provides a preservation layer for Windows software that Apple is unwilling to support themselves.

> the only feasible explanation is that Apple is hoping to somehow force developers into using Metal natively

I'm told the problem is some legal spat between Apple and Khronos that has led to a "no Khronos standards anywhere at Apple" policy. I don't know the details beyond that.

Sigh, sadly that sounds in-character. Pour one out for the users that didn't get their feature because a C-suite needed to make a point with their temper-tantrum.

Metal allows Apple to squeeze that extra performance out of their devices. They have full control over, and can implement whatever they need to deliver Apple Vision Pro for example.

With Vulkan, they would have to wait for a committee to approve required changes, and still they could not probably optimize it to match their GPU an CPU hardware profiles in such an efficient way.

And not least at all, to optimize the developer experience and tools. Apple GPU debugging tools are probably the best tools you get for graphics development debugging, and you get that only on macOS.

IMO Metal is a nicer API than Vulkan. At the same time, you can ask, why should Microsoft get to keep DirectX, and not just write a Vulkan driver ?

>Metal allows Apple to squeeze that extra performance out of their devices. They have full control over, and can implement whatever they need to deliver Apple Vision Pro for example.

That doesn't stop them from implementing both Metal and Vulkan.

Sure, but a lot of extra work for something like that. Also, Apple Walled Garden..

> they would have to wait for a committee to approve required changes

Or just make proprietary extensions?

> why should Microsoft get to keep DirectX, and not just write a Vulkan driver ?

They support both. And sometimes the Vulkan driver is faster than their native DirectX one too.

Like in the OpenGL days, Vulkan keeps playing catch up with the games consoles, and DirectX APIs, and it is already a extension mess just like OpenGL, an achievment in a quarter of OpenGL's lifetime.

You're confusing device-specific APIs with OS-specific APIs. There's a big difference. DX11, DX12, Metal, etc. are themselves all abstraction layers over what are in some cases very different hardware designs. (This will eventually become less so with Apple moving to in-house GPUs, but for now it's still true--Metal targets NVIDIA and AMD GPUs as well as Apple's M1/M2s.)

Maybe it'd be interesting to contemplate a world in which red team, green team, and blue team all have their own proprietary APIs and there are no cross-vendor abstractions, but that's not what we're discussing here.

>The Apple Metal platform surely is customized to the needs of Apple, its devices and its users ultimate needs, in a way Vulkan will never be.

Maybe Metal is customized to Apple's needs but how is it customized to Apple user's needs? One thing is for sure, had Apple been using Vulkan, the porting process to macOS would have been much easier.

> the porting process to macOS would have been much easier

Porting the 3D renderer to another 3D API isn't the hard part of a game port, but also:

Apple is offering a D3D12 porting toolkit since a little while which TBH makes a lot more sense than native Vulkan support (since there are so many more D3D12 games than Vulkan games):

https://developer.apple.com/games/

> Apple is offering a D3D12 porting toolkit since a little while which TBH makes a lot more sense than native Vulkan support

It would make more sense... if GPTK behaved like DXVK.

But instead, you're not allowed to distribute games with it, you can't easily modify it, and Apple themselves doesn't commit to supporting or updating it. Unlike Proton, which is community maintained, GPTK is Apple-maintained. If something breaks, your best option for "fixing" it is to run upstream DXVK on a properly supported machine.

> more ideological than practical grounded developers who accept that competition of private standards will bring out the best user experience, each platform having its customized architecture.

There's no clean answer here. You push that mentality of "Customers first" too hard, and you get the PS3; an unwieldy architecture that devs are forced to support but end up with worse ports than the Xbox 360. The customer doesn't necessarily "win" here.

You push developers first too hard and you get Linux. You can do anything you want if you dig deep enough. But as we all know, the common consumer barely reads the tutorial, let alone learns how to configure complex settings in a CLI.

There needs to be some middle ground, and not making developers duplicate their work for every new private business is at least a starting point.

>Maybe the society of worldwide developers had better things to do than spend precious time on Vulkan.

Given MacOS's marketshare, I'm sure they did. Let's not pretend that the few metal games we have on Desktop wasn't built on the grounds of some Candy Crush clone that generated billions of dollars 10 years ago and justified the forced upgrade (we can definitely justify from there if "making candy crush run faster" is a better thing to do. But it pays the bills, I guess).

Very few devs want to support Mac and the numbers speak for themselves.

   not making developers duplicate their work for every new private business is at least a starting point.

Im sure we all understand the benefits of a unified API / same abstraction layer. It’s about how the abstraction is leaking in real life and how to squeeze every last percent of developer’s experience and final application speed

I'd take Metal anyday over Vulkan though. It's simply the much more ergonomic and much better designed API. A native Vulkan version only really makes sense if Android needs to be supported (and this will be a rough ride because of the poor state of Android Vulkan drivers).

That's a shame, Metal supports proportionally less software and is maintained by a megalomaniac.

The commercial engine developers also don't have any qualms supporting GNM, GNMX, NVN.

Bugs notwithstanding (which I agree are a significant concern for Metal), I'd frankly much prefer to work with a well-designed, streamlined API like Metal instead of a needlesly verbose and complex Vulkan.

You can't ship Game Porting Toolkit with your game, though. DXVK doesn't have this limitation, and developers use it all the time. In effect, this means the number of games you get with native Vulkan coverage is a magnitude higher than the total sum of all Metal-native desktop titles.

This isn't completely true. Crossover is allowed to ship the GPTK components for API translation (which they currently do as of 23.5) and games are allowed to embed Crossover elements like they did in the pre-Metal days with Cider etc.

All this talk of DXVK doesn’t explain why games based on engines with native metal support aren’t on a Mac either.

Crossover is a paid product, and even then has pretty poor DX12 support compared to Proton. Up until a couple years ago it didn't work at all.

Again; if Apple had just supported Vulkan alongside Metal like a normal non-paranoid company, their users wouldn't be caught in the middle of this. It's such a blatantly obvious solution with no user-facing downsides. It's shocking that anyone would defend the status-quo when it's so notoriously and obviously broken.

Your assertions aren’t backed by history though.

Prior to metal and Vulkan, many games used Cider to target Mac despite having the same APi (at that point, an up to date OpenGL).

And many of the current game devs do have Metal versions of their engines that they target towards iOS, yet don’t have a macOS version.

The fact of the matter is that it comes down to market share. Macs have historically not had a large user base that also had capable GPUs. It’s not been worth supporting that tiny market share

It’s the same on Linux. Why are there so few Linux native games? The argument that Vulkan would have solved this is completely incongruent with the reality of the state of gaming.

This will inevitably go back to “well at least we could have used proton” but that’s also not true, and besides there’s GPTK. And then the argument becomes circular , because all evidence points to: devs just don’t care about Mac’s from a support perspective. You can make it easier, they still won’t come until the possible demographic size is larger.

and even with DXVK, what about all the other platform specific differences? Vulkan wouldn't solve those either.

I mean I owned a Mac back then, I remember pretty fondly that pre-Catalina MacOS was a fairly well-targeted platform. OpenGL was working for them; you could play first-person shooters, online games with fancy graphics, the kit and kaboodle. Things weren't perfect, but there was a lot of functional cross-platform software back when Apple commit to maintaining common APIs. You cannot deny that an entire ecosystem of software that was once cross-platform had to now choose sides, if they would support Metal or OpenGL. I watched it collapse with a single system update.

> Why are there so few Linux native games? The argument that Vulkan would have solved this is completely incongruent with the reality of the state of gaming.

My brother in Christ, the "reality of the state of gaming" is that Mac owners are buying Steam Decks just to access the games Apple tries to kneecap. Vulkan fixed it, and Valve commoditized Apple's compliment.

I don't want things to be this way. I think Mac owners should have easy access to the games they want to play, but Apple insisted otherwise for so long and refused to ever admit that they were wasting their time. It's part of the reason I got rid of my Mac so I could daily-drive Linux; they were wrong, and other platforms were right.

Go back and see how many of those games were running Cider though. The switch to kill 32-bit games killed more games than the deprecation of OpenGL did. The number of games that targeted OpenGL was ALSO shockingly low.

This is something that OSS fans do not want to reconcile: Open source graphics APIs have LONG lost out to proprietary graphics APIs in gaming. OpenGL had a very small base in games, Vulkan is even smaller.

and again, you went exactly back to where I knew you would and pre-empted it because it's the obvious playbook of answers. Vulkan didn't fix gaming on Linux. Proton did. And again, you ignore the key part of the sentence: NATIVE

Linux has fewer *native* AAA games than macOS. Vulkan has not solved that.

The SteamDeck is a product targeted at gamers that provided a new value proposition: AAA gaming on the go. Which further reinforces my point that API is irrelevant to the discussion, its about demographic. Apple has a strong gaming demographic on the mobile side (with metal no less).

The steam deck didn't introduce new Vulkan/Proton capabilities. Why was Linux gaming stagnant before it? Doesn't that exactly reinforce that its the form factor proposition that made it skyrocket?

> switch to kill 32-bit games killed more games than the deprecation of OpenGL did.

It did. If you want to parade around how cool Cider is, it doesn't make much sense to venerate the update that killed it.

> Linux has fewer native AAA games than macOS. Vulkan has not solved that.

Imagine all the Steam Deck users that are pissed because they can't play Resident Evil 8 and Tomb Raider natively! They must be super upset, and envious of Apple's superior native version. Surely.

Hey, here's a magic question for you; which do you think will get supported longer, a DirectX title running on Proton or an Apple-native title running on Apple software. Do you trust Apple to keep supporting your game as long as Proton would keep supporting it?

Considering backward compatibility on ios my bet is on proton for sure.

Why do you have tunnel vision on "native". It's a pretty meaningless distinction at this point. No steam deck users cares that all the games they are playing aren't "native".

Precisely. Modern games incorporate all manner of middleware to add functionality. Compression, video codecs, shading, ray tracing, physics, animation, anti-cheat. What's one more piece of software in the pile to abstract away platform-specific interfaces?

Also Wine it's just a Win32 subsystem for Unix with a PE loader. Also, a hint: on NT Systems, Win32 it's another subsystem on top of the NT kernel. I'm pretty sure Windows 95/98 software under 2000/XP doesn't run 'directly' in the same they did under their original OSes.

You are utterly wrong. Current Wine doesn't even need multilib.

> The argument that Vulkan would have solved this

but it in fact did! You can play 90% of games on linux precisely because of Vulkan. Just boot Steam Deck or whatever and play. There is no way it would work out without Vulkan

And I address Proton specifically in my comment and also address why it’s not an indicator of increased gaming support on Mac.

I truly feel half of the replies here are glossing over the things I’ve already covered and perhaps are people who haven’t actually tried the equivalent Mac solutions and seen where the resultant deficiencies lie or the delta between platforms that proton would also have to bridge further.

Vulkan isn’t the magical silver bullet people think it is.

Conversely, I'm convinced that you haven't tried Proton and are trying to defend Cider and Whiskey as analogs when in-fact they are pale imitations. Gaming on Mac is derelict; you can get a few games working, but it's still absolutely pathetic stood-up next to Windows or even modern Linux. The number of playable desktop games is just a blowout for MacOS.

We've all used tinker-tool applications to get a random app running through WINE, but DXVK is more than that. It is the solution to a problem Apple refuses to address, and even Apple is willing to admit that they need DirectX translation in order to make games run on Apple Silicon. How is the future of gaming on Mac going to look any different if we continue to follow in the footsteps of Cider? How long do you think that shanty-utopia will be supported on the latest OS update?

Vulkan has nothing to do with the Steam Deck being able to run PC games other than being the API that DXVK and VKD3D-proton translate DirectX calls into. Vulkan isn’t the magic bullet, it’s just another API in the stack. The “magic” is the phenomenal amount of effort that has gone into those DirectX translation libraries.

Vulkan makes the work easier, but it is not what makes those games portable.

Yes and no. DXVK didn't happen on top of opengl as the impendence mismatch between OpenGL and DX is too large. Wine had working but slow DX9 to OGL; incomplete, buggy and slow DX11 to OGL; and no hope for DX12 to OGL. DX9, DX11 and DX12 are all much easier (but not easy, mind) to map to Vulkan.

As Steam Deck is running AMD, a conversion layer on top of Mesa Gallium would have been possible, but again DX12 support never materialized.

Vulkan has a lot of features made specifically so that implementing portability layers like DXVK and Zink would be possible and performant.

This has been a key project in the past few years and lots of work went into it. For more info, look up Vulkan portability initiative.

While it might be true, I'd recommend to check if the licenses do, in fact, recurse this way.

They might not.

> The number of games that run natively on Vulkan is negligible.

Yep, that's unfortunately true...

https://www.carette.xyz/posts/state_of_vulkan_2024/

I'd be curious to see how many Vulkan-native games there are that don't run under Proton. The only one that comes to mind is Destiny 2, but that was more because of anticheat as I remember it.

Much of the Vulkan support was motivated by Stadia, not so much because Stadia was successful, but because Google was throwing huge amounts of money at developers to port their games to Stadia regardless. When Stadia was discontinued at the end of 2022, sure enough the number of new Vulkan games immediately plummeted.

Why is this article comparing game engines with games?

What do you mean? I guess most engines support Vulkan but that's not the point of the article, but you might be referring to something else.

these days, is the way to win in the industry to basically pour money into the popularity contest of your own dev kit vs. Nvidia's and others?

Star Citizen is another one recently moving to Vulkan, they just rolled it out as a graphics option in 3.23, and it's slated to replace DX11 once it's working well

> Vulkan Renderer has now been enabled in Star Citizen. This new renderer will be off by default but has been added to the Graphics settings menu. In this first release, the focus is on hardware/driver issues, stability, and any major performance issues. At this point we do not expect Vulkan to be outperforming D3D11 on the CPU usage due to the fact we haven't enabled multi-threading of the rendering submission yet, but do expect CPU performance to be within a 30% margin. Once we have multi-threading enabled we expect a significant net-gain. On the GPU side we should be closer to parity.

> Performance improvements and stability improvements will be on-going throughout 3.23, with the aim to make Vulkan the default and more performant implementation in a following release. In the meantime we appreciate any and all feedback towards this.

> Additionally, you may see a few new folders now in Star Citizen's appdata. These relate to our new Graphics Settings file (just includes the Graphics Renderer setting for now), Vulkan's Shader Cache, and Vulkan's Pipeline Cache.

> We are currently working with AMD and Nvidia to improve functionality and compatibility for later Driver Releases. It is recommended that you update to the latest GPU drivers for this release but there are still a few known issues that could cause instability and crashes with Vulkan until a later AMD/Nvidia Driver update. If you run into major issues you may want to swap back to DX 11. If the game crashes on launch after switching to Vulkan, you can reset this by deleting your shader folders in %localappdata%\Star Citizen

https://robertsspaceindustries.com/comm-link//19915-Star-Cit...

> Star Citizen is another one recently moving to Vulkan, they just rolled it out as a graphics option in 3.23, and it's slated to replace DX11 once it's working well

Does it work well in Wine on Linux with Vulkan renderer now? I tried a long time ago and I was waiting for their Vulkan option to revisit it.

Haven't tried it, but this person says no

https://www.reddit.com/r/starcitizen/comments/1cl0bwn/star_c...

Interesting. Looks like it works but with poor performance. I guess I'll wait for them to finish the rest of the work to enable more parallelism first.

Also, did they start using EAC? That usually works very badly in Wine unless developers flip some switch to allow it on their side?

It does have EAC, but I don't think it's as aggressively enforced as some games since people are still able to run it on Linux.

There's a Linux Users Group that would know much more about it than I do.

https://robertsspaceindustries.com/orgs/LUG

>The number of games that run natively on Vulkan is negligible

Firstly, several games engines and rendering libraries support it.

Secondly, it does not have to be _native_, on top of Vulkan you can run OpenGL and Direct3D emulation layers, which will cover most of the rest. macOS has long since abandoned their native OpenGL drivers, and MoltenVK has many caveats.

> Firstly, several games engines and rendering libraries support it.

So? If no one is using that support to ship PC games using Vulkan, who cares? Those same engines all support Metal, so clearly this is irrelevant to the question of Mac gaming.

>The number of games that run on Metal by comparison (natively) is orders of magnitude higher.

When it's the only way to interface with MacOS and especially IOS, I'm not surprised. But that says more about Apple as a platform than Vulkan as a graphics API.

>Apple does now have Game Porting Toolkit

yup, only took some 9 years after they abandoned Khronos to get it up and running. I'm sure nothing signifigant would have developed in that time.

I think you make a good point in general, but "likely not really have helped macOS gaming in any form" I think is taking it too far. The reason why many developers only use dx11/12 is because adding more graphics backends increases their support surface unnecessarily, being that Vulkan only works on Windows (and Linux), while dx11/12 work on Windows on Xbox. As an extreme example of this, apparently Cyberpunk 2077 ran Vulkan on Stadia but did not enable it for Windows as an option. (Because what is the point?) If Vulkan worked on both Windows and Mac then developers would have more reason to support it. It would likely also mean game engines would put more time into making Vulkan better. For a related example, Apple had to individually contribute it's Metal backend to Blender because (presumably) nobody wanted to work on it.[0] Why? Because they already have to support OpenGL, Cuda, OptiX, Intel OneAPI, ROCm HIP, and Vulkan. Clearly, something is very wrong with graphics APIs right now. If Apple supported Vulkan, it would have allowed everyone who is not Windows to benefit by making Vulkan become more standard. Luckily Xbox seems to be kind of dying right now so perhaps supporting dx11/12 will not be as important in the future. But the point is if you have a small portion of the market it just doesn't make sense for developers to spend time entering that market for little reward.

Another major point is the development cycle. Since Metal only works on Apple devices that makes developing for it more annoying for game developers which are mainly using Windows. It means they will have to switch to a Mac device to debug issues with their Metal backend. By supporting Vulkan Apple would allow for a much smoother developer experience. (While Metal Developer Tools for Windows exists, as I understand it it only allows you to compile shaders for Metal on Windows, but to actually test that anything works you will need an actual MacOS device.).

[0] https://code.blender.org/2023/01/introducing-the-blender-met...

Many engines support Metal, in addition to the plethora of console specific APIs. Saying DX11/12 works on Xbox is glossing over that that it's not actually the same DX12 that works on desktop.

You then say that if they used Vulkan, it would mean they wouldn't have to debug on a Mac. This is overly optimistic. Even in the OpenGL days, you'd have to test on all platforms because there's so many variances. In general, the game designers are rarely working multi platform, and it's down to the engine devs themselves + QA. Neither should or would be blindly trusting that things are portable. Vulkan/DX on AMD/NVIDIA also perform differently enough that you can't just assume parity.

Your other statement about nobody wanting to work on Metal for Blender is a bit odd too. There's no current Vulkan or DX backend for it. Does that mean they're not desired either? AMD and NvidiA contribute support for their favoured API's as well, like Optix that people still desire.

> If Apple supported Vulkan, it would have allowed everyone who is not Windows to benefit by making Vulkan become more standard.

This didn't prove itself out when OpenGL was a thing. OpenGL was everywhere but barely used.

> Luckily Xbox seems to be kind of dying right now so perhaps supporting dx11/12 will not be as important in the future.

That doesn't mean that Vulkan would replace it though. Windows gaming still eclipses Linux, and game developers have to target multiple APIs either way. There's very little upside to them switching to Vulkan for it.

Also bear in mind that DX is much more than D3D. It's a lot of APIs. There's many reasons to use DX beyond just the 3D graphics APIs.

>if they used Vulkan, it would mean they wouldn't have to debug on a Mac.[...] Neither should or would be blindly trusting that things are portable

I didn't mean this, just that you can actually run whatever shaders you compile rather than needing a Mac just to see your output. My point was that you would get "a smoother developer experience," which is true.

> Vulkan/DX on AMD/NVIDIA also perform differently enough that you can't just assume parity.

Vulkan has some pretty strict conformance tests[0]. It's not like you are going to run into differences between conformant Vulkan implementations every day. It's very different from not being able to run the shaders you've compiled at all. You just need to know what extensions are supported. Also, Apple's support for OpenGL was never good. They only supported OpenGL 4.1 for years while 4.5 was out, for example. I don't know if Apple's OpenGL was ever even conformant, being that 4.1 is not listed on the site.[1]

>There's no current Vulkan or DX backend for it.

There is actually (as an experimental feature currently).[2] And Khronos did not have to send developers to implement it for them. My understanding is that Blender also implemented CUDA/Optix themsleves and only got help from Nvidia, rather than Nvidia implement the whole thing for them, although I could easily be wrong there.

>This didn't prove itself out when OpenGL was a thing. OpenGL was everywhere but barely used.

OpenGL was not nearly as performant as direct X. When Direct X came out people switched to it. Vulkan and dx12 are very similar however.

> That doesn't mean that Vulkan would replace it though

Yeah, because each console wants their own special graphics API to force on everyone instead of using an open standard, despite Xbox and Playstation GPUs being from AMD which supports Vulkan on it's consumer GPUs.

>Many engines support Metal, in addition to the plethora of console specific APIs

And many don't, including the engines of a lot of AAA games like Elden Ring, Cyber Punk 2077 and Baldur's Gate 3 (although CDPR are now switching to UE5). And studios are generally using modified versions of UE so my guess is that means they are generally making low level changes sometimes, and so it makes sense to me that they sometimes may write their Dx/ Vulkan code for different things sometimes. (this is just my guess. I admit to being uninformed here). Even if not there are still ways that you could program something in UE without writing any direct DX/Vulkan code that could still result in worse performance for one of the backends vs. the other. That is why on games that support multiple graphics backends oftentimes one is better than the other. And developers will release updates improving only certain backends. Adding an extra platform like MacOS is not simply clicking a button. although it is easier today than before, if it was that simple, then literally every UE game would be on MacOS. (Yes, you do 'just click a button' to support MacOS in UE5, but there is still more to it than that.) And increasing the surface area of platform divergence does nothing to help the situation. Also, while it doesn't matter for Apple, having to maintain multiple backends adds needless extra work for engine developers

[0] https://docs.vulkan.org/guide/latest/vulkan_cts.html

[1] https://www.khronos.org/conformance/adopters/conformant-prod...

[2] https://code.blender.org/2023/10/vulkan-project-update/

Ultimately, the whole discussion surrounding technologies is discussing the consequences of the problems, not the problem itself.

The problem is that Apple, since it decided it was going to make its own GPUs for all its devices, deemed it necessary to simplify their support. Apple's Metal API is custom-made to the silicon Apple is making, and Apple keeps Metal development strictly focused on their hardware. Of course they could have chosen to support more APIs, but the strength of iOS clearly helped them decide to move iOS game developers to the Mac, rather than try to court the so-called AAA companies who are stuck in an x86, Windows+console, heat up the wazoo world. That whole world is difficult to reconcile with Apple's priorities.

>Apple's Metal API is custom-made to the silicon Apple is making

Do you have any examples of this? My guess is that the API, being higher level than vk/dx, is designed for ease of use by developers, not to expose hardware level details. In fact Vulkan would be more suitable for that as it is lower level.

>the strength of iOS clearly helped them decide to move iOS game developers to the Mac

What do you mean by this? Are there a lot of mobile game studios publishing on MacOS now? (this is a legitimate question)

>rather than try to court the so-called AAA companies who are stuck in an x86, Windows+console, heat up the wazoo world.

Why is that? The only actual barrier there is x86. But Vulkan is not related to x86 anyway. It is only related inasmuchas they are both not supported by Apple. But this discussion is itslef about if Apple should support Vulkan, so the reasoning here seems circular. Also, if Apple doesn't like x86 games that is fine because they don't support x86. So it's not like they are not support Vulkan because they think developers will start distributing x86 games to their customers because that's impossible.

>heat up the wazoo

I mean, it will use the same about of energy as any other demanding application like Blender or video editing. And you can always lower the graphical settings to make it consume less power. Similarly mobile game developers would likely increase the graphical settings for a mobile game that they port to MacOS.

I don't really know if it counts as 'exposing hardware details,' and I may be wrong, but this could be an example of where in their API it does make more sense for Apple Metal being separate.

The example I am thinking of is with MTLBuffers and storage options. You have several different storage options for MTLBuffers that wouldn't necessarily make sense on non-apple hardware and especially non-apple silicon. Options that are not backwards compatible with intel macs. When I go to use MTKTextureLoader with the newTexture command, I can set in the options an MTKTextureLoader.Option.StorageMode as shared storage. On Apple silicon, this means that the it is a shared buffer by both the CPU and GPU since with the apple silicon architecture the came peice of memory can be accessed by both. There are a bunch of different storage options that may not apply to other configurations outside of the Apple silicon configurations.

> My guess is that the API, being higher level than vk/dx

Metal is not generally higher level than VK/D3D12, instead it's a mix of high- and low-level features (where the low level features typically had been added in later Metal versions and are optional to use).

You can stick to the convenient high level parts of Metal v1 (which feels a lot like the spiritual successor to D3D11) if that's good enough (which often is), but if needed there are lower level and more explicit features that match or in some parts go beyond what Vulkan and D3D12 have to offer (AFAIK argument buffers allow a couple of things that are not possible on D3D12 or Vulkan, or at least would require vendor specific extensions on Vulkan - like setting the PSO via an argument buffer, recorded in a compute shader).

> Yes, you do 'just click a button' to support MacOS in UE5, but there is still more to it than that.

Can you expand on this? What happens / doesn’t happen when clicking that button? Is debugging the additional effort, or incompatibilities?

> Vulkan has some pretty strict conformance tests[0]. It's not like you are going to run into differences between conformant Vulkan implementations every day.

Oh man with every fibre of my being do I wish this were true. I’m debugging a different Vulkan driver bug almost every 2 weeks. PC drivers are passable, mobile drivers are a joke. Shader miscompilations everywhere. Performance traps. Arm Mali drivers currently implement vkCmdPipelineBarrier2 by calling vkCmdPipelineBarrier in a loop for every individual barrier instead of issuing a single barrier. I’ve measured Barrier2 as almost 10 times slower than the older version, only on Arm drivers though.

You have to test everywhere

It isn't perfect but it's so much better than it used to be.

Mobile drivers are still a problem, and part of the problem is that they passed their conformance tests years ago, and the test suite has improved a lot since then.

But it's a giant surface area to test, it is not perfect. But still better than what we had 10 years ago.

> You then say that if they used Vulkan, it would mean they wouldn't have to debug on a Mac. This is overly optimistic.

Sure, but supporting two variants of Vulkan is less work than having to support two incompatible APIs. It's not a binary thing.

The problem is that there isn't two variants, there is an extension soup of Vulkan variants.

I get by just fine with "one variant" using all the Vulkan 1.3 features that are ubiquitously available on desktop (= almost all of them) platforms with up to date drivers.

The fact that there's n+1 extensions does not mean you have to support 2^(n+1) combinations. I can't recall a single situation where I would've needed even two code paths to get something done in the past few years.

Situations where you need two or more code paths only arise if you use new hardware features like mesh shaders or ray tracing. For "software" features like dynamic rendering or dynamic states (both of which simplify things a lot), there's no need for a fallback on desktop, just require a recent driver version and you're good.

That said, the mobile driver support situation and lack of long term updates is an issue if mobile support is required.

>The number of games that run on Metal by comparison (natively) is orders of magnitude higher.

You mean iOS games?

It is still Metal, regardless.

But since there are more Android phones, there are more devices supporting Vulkan than devices supporting Metal.

Only if you ignore the facts that Vulkan is only a required API since Android 10, it is an ecosystem full of buggy drivers, there are no updates, what exact version of Vulkan and extension spaghetti varies widely by phone, and only Samsung and Google Pixel phones, do actually offer a sane Vulkan experience.

Everyone that wants to keep their 3D sanity keeps targeting OpenGL ES, which is exactly why Google is now doing ANGLE on top of Vulkan as means to pressure OEMs to deliver proper Vulkan drivers.

You are literally comparing a bunch of gambling apps to a library of desktop gaming experiences.

"It is still Metal, regardless" you say, with your mind scrolling full of Zynga dice-rolling games and Supercell micro-transaction machines.

I am comparing what brings money home, big boys club money, versus hippie feel good complaints.

I am comparing where the quality titles live. I (and most people who have the freedom of choosing) do not even pay a second thought to those shitty mobile casino apps.

Crazy stuff like that happens, when you have access to quality entertainment and not drip-feed gatcha games.

Yeah, they would rather spend their money on Playstation, Nintendo and Microsoft consoles, also no Vulkan.

> Vulkan would likely not really have helped macOS gaming in any form

Why not? With fully conformant Vulkan you could have run all the games that work in Wine without being hit by limitations of MoltenVK that affect performance and compatibility, same as you can run them on Linux now. So Vulkan could totally be very crucial for making gaming on macOS not being some second class experience.

Apple simply demonstrate they don't care about gaming and gamers. They only care about "approved by Apple way of gaming" which is totally not the same thing but which Apple always does for everything anyway, shoving in users' faces "we know better than you what you need".

That's why I will always say that gamers should avoid using Apple.

You can't "just support Vulkan", it's too low level. To benefit, the implementation would have to target the GPU specifically since Apple GPUs are different from discrete GPUs.

Well, Asahi / Mesa developers demonstrated that they can "just support Vulkan" on Apple's hardware as the linked post explains. So Apple never had any excuse for not doing it. Their reasons for sabotaging Vulkan support were always political, not technical.

Sabotaging? Metal came before Vulkan.

How does that stop Apple from supporting Vulkan on their system? It is pure political sabotaging. And you can't pull any excuses like "it requires effort". Apple have pools of cash to do the right thing for users and developers. They simply very intentionally oppose it due to their dinosaur lock-in mentality.

A blog post is different from a real compliant commercial implementation. Other reasons you couldn't do it include eg someone with a patent on it won't license it to you.

Mesa's implementation will get a compliance certification once it's ready. I don't see why they would have problems with that - other Vulkan drivers got compliance from Khronos once they passed needed tests. Patent FUDs are nonsense - no one else has such issues and many drivers already exist and work fine.

The real reasons are not good at all (i.e. Apple's obsession with lock-in) and have no excuse.

> A blog post is different from a real compliant commercial implementation.

honeykrisp is already a "real conformant" implementation and is listed on Khronos's website already.

https://www.khronos.org/conformance/adopters/conformant-prod...

You left out a word.

https://github.com/KhronosGroup/MoltenVK proves that it is possible, but it is limited by having to go through Metal.

Anything's possible, but it wouldn't be performant. MoltenVK is just about as good as an untuned native Vulkan client would be.

If Apple would add native Vulkan support to macOS, it would most likely also go through a Metal "emulation layer" (just like their GL implementation, or the D3D12 implementation in the Game Porting Toolkit).

Because everyone knows from MoltenVK, Metal-based API implementations are just so efficient.

Reply on news.ycombinator.com