return to table of content

Vulkan1.3 on the M1 in one month

dagmx
181 replies
1d2h

Very impressive work, and a great testament to the value of shared, iterative and open components.

I'll be curious how long it takes Proton to be ported, though I suspect even with an optimal Vk implementation, many games will run terribly due to the difference in GPU architecture + arm translation overhead + proton itself (however negligible).

Still, I remain optimistic that more games will target unified memory and ARM in the future on desktops, as SoCs become more prevalent like the snapdragon.

talldayo
178 replies
1d2h

There will be a small bit of irony if the gaming experience on Asahi ends up easier and more straightforward than MacOS.

Really just drives home how big of a mistake it was ignoring Vulkan for the past decade on Apple's behalf, but lord knows they won't admit that until it's too late.

dagmx
101 replies
1d1h

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.

pcwalton
37 replies
22h18m

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.

ttoinou
32 replies
19h24m

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.

_carbyau_
14 replies
18h46m

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

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

dev_tty01
13 replies
17h54m

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?

_carbyau_
5 replies
14h48m

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....

pjmlp
2 replies
10h57m

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

SleepyMyroslav
1 replies
10h33m

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.

pjmlp
0 replies
9h28m

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.

troupo
1 replies
5h23m

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

talldayo
0 replies
2h18m

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?

atq2119
3 replies
12h19m

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

pjmlp
2 replies
10h58m

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.

talldayo
1 replies
2h17m

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.

pjmlp
0 replies
12m

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.

nemomarx
2 replies
17h33m

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.

jppittma
1 replies
16h58m

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.

mycocola
0 replies
12h15m

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

talldayo
10 replies
18h40m

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.

inDigiNeous
4 replies
13h1m

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 ?

DeathArrow
1 replies
11h56m

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.

inDigiNeous
0 replies
11h26m

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

talldayo
0 replies
1h43m

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.

IsTom
0 replies
7h55m

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

Or just make proprietary extensions?

ttoinou
1 replies
18h28m

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 ?

talldayo
0 replies
18h1m

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.

pcwalton
1 replies
16h54m

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.

talldayo
0 replies
14h0m

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.

pjmlp
0 replies
11h0m

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.

DeathArrow
2 replies
12h0m

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.

flohofwoe
1 replies
11h39m

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/

talldayo
0 replies
1h44m

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.

johnnyanmac
1 replies
8h33m

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.

ttoinou
0 replies
5h44m

   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

pcwalton
0 replies
16h55m

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.

flohofwoe
1 replies
11h45m

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).

talldayo
0 replies
2h21m

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

ribit
0 replies
10h37m

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.

pjmlp
0 replies
11h2m

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

talldayo
18 replies
1d1h

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.

dagmx
17 replies
1d1h

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.

talldayo
15 replies
1d1h

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.

dagmx
14 replies
1d1h

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.

talldayo
7 replies
1d1h

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.

dagmx
6 replies
1d1h

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?

rowanG077
2 replies
21h20m

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".

jakogut
1 replies
20h43m

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?

anthk
0 replies
7h45m

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.

talldayo
1 replies
1d1h

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?

christkv
0 replies
23h52m

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

anthk
0 replies
7h48m

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

out_of_protocol
5 replies
1d

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

MindSpunk
2 replies
16h32m

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.

gpderetta
0 replies
6h36m

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.

exDM69
0 replies
6h15m

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.

dagmx
1 replies
23h22m

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.

talldayo
0 replies
1h37m

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?

p_l
0 replies
1d1h

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

They might not.

fngjdflmdflg
12 replies
1d

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...

dagmx
11 replies
23h54m

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.

fngjdflmdflg
7 replies
22h48m

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/

philistine
3 replies
21h31m

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.

fngjdflmdflg
2 replies
21h6m

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.

tcmart14
0 replies
14h31m

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.

flohofwoe
0 replies
11h31m

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).

MindSpunk
1 replies
16h17m

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

exDM69
0 replies
6h7m

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.

robertoandred
0 replies
20h4m

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?

pcwalton
2 replies
22h14m

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.

pjmlp
1 replies
10h54m

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

exDM69
0 replies
8h47m

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.

shmerl
10 replies
1d

> 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.

astrange
9 replies
23h56m

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.

shmerl
4 replies
20h8m

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.

robertoandred
3 replies
19h57m

Sabotaging? Metal came before Vulkan.

shmerl
2 replies
19h41m

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.

astrange
1 replies
16h42m

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.

shmerl
0 replies
16h5m

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.

flohofwoe
1 replies
11h19m

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).

talldayo
0 replies
2h22m

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

astrange
0 replies
16h38m

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

wlesieutre
4 replies
19h52m

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...

shmerl
3 replies
19h46m

> 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.

shmerl
1 replies
16h18m

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?

wlesieutre
0 replies
4h34m

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

tapoxi
1 replies
1d

Why is this article comparing game engines with games?

mardifoufs
0 replies
21h42m

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.

talldayo
0 replies
1d1h

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.

jsheard
0 replies
1d1h

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.

caycep
0 replies
22h57m

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?

DeathArrow
5 replies
12h4m

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

You mean iOS games?

pjmlp
4 replies
10h55m

It is still Metal, regardless.

talldayo
1 replies
2h6m

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.

pjmlp
0 replies
13m

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

DeathArrow
1 replies
10h50m

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

pjmlp
0 replies
9h28m

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.

SoothingSorbet
1 replies
15h4m

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.

lonjil
0 replies
6h4m

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.

johnnyanmac
0 replies
8h41m

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.

rowanG077
21 replies
1d2h

Why would that be ironic. Apple wilfully is holding gaming back on OSX by ignoring Vulkan and having a pure shit opengl implementation.

bilbo0s
20 replies
1d1h

You may have a good point with the opengl thing. But the number of games that run on Vulkan is so vanishingly small that we can't credibly say that not having a Vulkan driver holds Apple back on gaming. I'd bet any money that the number of games that work on Metal is wayyyy higher than the minuscule number of games that run on Vulkan. Which should tell you how few Vulkan games there are.

talldayo
10 replies
1d1h

But the number of games that run on Vulkan is so vanishingly small

Really? 7 out of the 10 most popular games on Steam work fine if you have Vulkan 1.3 drivers: https://www.protondb.com/explore?sort=playerCount

dagmx
9 replies
1d1h

of the top 10, I count 3:

Counter Strike 2 Dota 2 Stardew Valley

How are you getting 7/10 unless you're also counting games that happen to run under Proton, which aren't native? And regardless, that's a really small sample size to extrapolate from, when it's easy to get a more extensive list that is around ~250 games total.

https://www.vulkan.org/made-with-vulkan https://www.pcgamingwiki.com/wiki/List_of_Vulkan_games

Of which, a massive percentage are based on engines that have Metal support as well.

talldayo
8 replies
1d1h

I'm sorting by playercount, which seems to be corroberated here: https://steamcharts.com/top

I am counting Proton games because they very explicitly are supported by sufficient Vulkan coverage. In case you weren't paying attention that's kinda the only reason anyone cares about Apple Silicon getting Vulkan 1.3 coverage in the first place.

when it's easy to get a more extensive list that is around ~250 games total.

You're right, when we push it out to 1000 titles it gets closer to 80% playable: https://www.protondb.com/dashboard

Of which, a massive percentage are based on engines that have Metal support as well.

...yeah, you keep telling yourself that. One day, they'll definitely flip the switch on MacOS support. Certainly.

dagmx
7 replies
1d1h

Okay, so you're counting non-native games when the discussion is AGAIN clearly about native games. If we're talking about translation layers, then it's irrelevant because Whisky/Crossover can run them as well.

This is just you being completely disingenuous now and purposefully avoiding the actual point of the discussion.

tracker1
4 replies
23h16m

I think it's absolutely fair to count games that are able to run in Linux with Proton via DXVK + Vulcan. Since it's well established and relatively popular thanks to Valve's efforts with the Steam Deck and Proton.

Given those efforts, if Apple/Mac had support for Vulkan, Valve would probably make it all just as available on Mac as they do on Linux for Proton.

vilunov
1 replies
17h10m

Even with Vulkan support on macOS it would be harder for Valve to make many games accessible as they do on Linux – unlike Linux, macOS does not support running 32-bit binaries anymore.

guipsp
0 replies
16h17m

You'd be correct a few years ago, but not anymore. WOW64 mode is pretty good nowadays.

robertlagrant
1 replies
21h57m

Well - they might. I don't think Valve would hate being the gaming gateway for Mac as well as for PC, but they have great Linux support because of the Steam Deck.

talldayo
0 replies
21h29m

If I'm not mistaken, supporting MacOS with Proton was the implicit plan before Apple disabled 32-bit support in Catalina. Several people seem to have gotten early builds to compile on Mac with usable performance: https://github.com/ValveSoftware/Proton/issues/1344

talldayo
0 replies
1d1h

This was never about native games. It would be very convenient if Proton didn't exist and native games were the only playable option, but in many cases Proton titles run better than native Windows. It's an equivalent, if not superior, experience.

It would be a lot more disingenuous if the Steam Deck didn't exist and Linux gaming was a farce. But... it's not. And the only thing stopping Apple from enjoying the same spoils is a little bit of humility.

rowanG077
0 replies
23h6m

Dxvk is notoriously bad on moltenvk. I have tried and have completely given up running it.

jeroenhd
8 replies
23h49m

The amount of games that work with Vulkan may be very small, but at least they have a chance of working. The de facto standard API for games on computers, DirectX, will never receive a port.

If you think Vulkan support for games is insignificant, look at Metal support.

I think Vulkan makes a lot of sense for macOS, actually; the Nintendo Switch, to which tons of games have been ported already, uses the ARM+Vulkan design and has a relatively weak GPU (but much weaker, as it's very old). It's not quite native, but a lot of supporting libraries that work on the Switch will also work on Mac. Everyone is talking about porting Windows games to Mac, but with the way things are developing, porting Switch games to Mac may actually make more sense, assuming Nintendo's promises for the upcoming Switch replacement are to be believed.

troupo
6 replies
21h35m

If you think Vulkan support for games is insignificant, look at Metal support.

Metal is supported on iOS. You know, one of the largest gaming platforms in the world.

philistine
5 replies
21h23m

THE largest gaming platform in the world. Users, sales, number of games, hours played.

I challenge you to find one metric where the iPhone isn't number one.

guipsp
1 replies
16h19m

Not true on either users, number of games, or hours played.

Remember, android exists, and supports vk.

pjmlp
0 replies
10h51m

Only since version 10, as required API, it was optional between Android 7 and 10, and unless you are into Samsung or Google Pixel Android phones, good luck.

talldayo
0 replies
20h49m

I challenge you to find one metric where the iPhone isn't number one.

Enjoyable gaming experiences?

amlib
0 replies
20h21m

And yet most popular games on phones (both ios and android) are complete shit full of predatory practices with appalling gameplay and simple graphics, which barely benefit from those fancy graphics API anyway and could be reworked within weeks to use any other API.

I do know apple is trying to push for AAA games on iphone but so far its a small drip on a giant cesspool.

If you want actual good games, be it indies, AA or AAA, you go for one of the three consoles, windows or steam deck/linux.

Dylan16807
0 replies
4h52m

What happens if we exclude games that could run in a browser canvas with no webgl support? They don't really benefit from the API choice.

flohofwoe
0 replies
9h51m

The de facto standard API for games on computers, DirectX, will never receive a port.

Apple did just that with the Game Porting Toolkit.

If you think Vulkan support for games is insignificant, look at Metal support.

Pretty much all iOS games run on top of Metal.

burnte
19 replies
23h59m

Really just drives home how big of a mistake it was ignoring Vulkan for the past decade on Apple's behalf, but lord knows they won't admit that until it's too late.

They'll never admit it. They only caved on USB-C because they were legally required to. They won't cave on this, or NVidia support, or putting the charge port on the side of the mouse and not the belly, etc.

mantas
11 replies
23h44m

Nobody required USB-C charging for laptops and iPads. It would have happened on iPhones eventually too.

eptcyka
10 replies
23h34m

They were the (one of the) first ones to usb-c on laptops. I don’t think they were ever planning to do usb-c on the iPhone, they had no reason to be this late.

chipotle_coyote
4 replies
23h12m

They didn't have a technical reason to be that late, but they probably had a marketing reason -- and I don't mean "they made money by licensing Lightning." (They did, obviously, but I don't think it was raking in big bucks, at least not Apple standards.)

When the iPhone switched to Lightning from the clunky 34-pin iPod connector, a whole lot of people got pissed off with Apple and stayed pissed off with them for years. Literally years. People were convinced Apple did it just to sell more cables. So if you're Apple, and you know the history of the last time you forced everyone to buy new cables, and now you have orders of magnitude more people using your phone…you probably put this off as absolutely long as possible.

Would they have gotten there without pressure from the EU? Honestly, I think so -- I used to agree with you, but when the iPad Air, not just the Pro, went to USB-C, I changed my mind.

kalleboo
3 replies
15h44m

When Apple went up on stage and announced Lightning, they said "this is our connector for the next 10 years".

10 years later, almost on the dot, they replaced Lightning on the iPhone with USB-C.

Doesn't seem weird at all to me.

talldayo
2 replies
13h53m

It wouldn't be weird if they simply picked one side and stuck with it. They put USB-C on Mac, because obviously Lightning couldn't fill the role they wanted with Thunderbolt. And then they made iPhones Lightning because... they wanted to sell IP to cable manufacturers. And they made the Magic Trackpad/Keyboard accessories use Lightning because... why again? It's just USB, it probably takes more work to make a Lightning peripheral than a USB-C one.

The more you think about MFi and Lightning design patents the harder it is to believe that they were simply being honest and sticking to their word.

troupo
1 replies
5h14m

When they made Lightning USB didn't even have an agreed-upon charging standard. Much less all the other requirements Apple had for the cable.

Do not try and pretend that USB was any good when Lightning was announced. And even USB-C is a mess of conflicting and confusing optional specifications.

talldayo
0 replies
1h53m

And even USB-C is a mess of conflicting and confusing optional specifications.

Certainly one that Apple didn't struggle to navigate, considering they designed Thunderbolt around the specification.

philistine
3 replies
21h25m

Apple did USB-C on the iPad before the Europeans forced them to do USB-C at all. They could have kept developing Lighting, it supported USB-3 speeds for one device (the first iPad Pro), but they instead chose to rally around the common standard. USB-C on phones was a certainty, it was clear to everyone. The problem is not that Apple didn't want to standardize, it's that they didn't want to be forced.

In the history of technology, Apple has chosen to switch connectors countless times. Every single time people complain, and every time Apple has the same exact reason for choosing a specific connector: its the one that makes sense for its customers when the device is released.

talldayo
0 replies
20h52m

Speaking of, can you buy a Magic Trackpad that uses USB-C yet? I've got a Magic Trackpad 2 that requires this annoying special cable no one uses and it ends up making me buy trashy gas-station connectors to feed it power.

Maybe we're still waiting for that one to make "sense for it's customers when the device was released". Good grief.

ThatPlayer
0 replies
20h51m

it supported USB-3 speeds for one device (the first iPad Pro)

I'm always unsure about this because it only supported USB 3 host for one specific accessory, the camera adapter. I question whether that implementation was just a hack or something that could've scaled to proper USB client support and others.

There was never a USB 3 Lightning to USB-A or USB-C cable.

Dylan16807
0 replies
5h5m

They did the exact opposite of rally. USB-C on iPhone took an extra eight years. Even if I agree it was a "certainty", that's far too long.

They did not want to standardize. The idea of forcing them didn't come up in any significant way until after they proved that.

And I don't know what their laziness about USB 3 is supposed to prove. They didn't consider 3 support necessary for USB-C either.

oreilles
0 replies
9h57m

Actually they had one, they released the Lightning connector by claiming they would stick with it for at least a decade. And they did exactly that.

troupo
5 replies
21h32m

They'll never admit it.

Admit what? That they had their own API before anyone even thought about Vulkan? That they have Metal running on one of the most popular platforms in the world (iOS)? That other major platforms don't support Vulkan (Xbox, Playstation; Windows supports DX and defers Vulkan support to GPU vendors)?

talldayo
2 replies
20h49m

Admit that Metal isn't enough.

People were more willing to write a DirectX translation framework for Vulkan than Mac users were willing to write one for Metal. And now with Game Porting Toolkit we basically have confirmation that nothing has been stopping Mac users from playing DirectX games with DXVK besides... working Vulkan drivers.

So it would be nice to see Apple's explanation for being so insular. Especially when their "solution" is repackaged and relicensed free software that we've all been using for years.

troupo
1 replies
9h29m

Admit that Metal isn't enough.

By what criteria?

People were more willing to write a DirectX translation framework for Vulkan than Mac users were willing to write one for Metal.

There were significantly more games playable on Mac than for Linux for years, even after Vulkan's introduction. Apple hurt gaming on Mac by dropping 32-bit support and changing CPU architectures significantly more than any fantasy about not supporting Vulkan (which is really not supported by most major platforms, and isn't supported by game developers either).

And it wasn't some vague nebulous people willing to write a DirectX translation framework. It was Steam pursuing its business strategy (and doing an amazing job of it). Before steam not a single person could be bothered to get off their asses and do a similar job for any platform.

talldayo
0 replies
1h54m

By what criteria?

...games? Isn't that what we're talking about? How Apple suffers from spurning the gaming industry, and does absolutely nothing to improve the scenario?

There were significantly more games playable on Mac than for Linux for years

Apple hurt gaming on Mac by dropping 32-bit support and changing CPU architectures significantly more than any fantasy about not supporting Vulkan

Oh, well this is just wrong. Box86 had "solved" the x86 -> ARM translation path before Apple Silicon even existed, albeit slowly. The 32-bit depreciation was bad, but wasn't a dealbreaker for applications like WINE; there is a working codepath for WOW64 in WINE today.

Once again; the OP's post is about how they currently have games working on Linux that are flat-out unplayable on MacOS. Whether you want to blame fantasy features or not, Apple has clearly made some sort of arbitrary limitation on the userland capabilities that has stopped developers from doing this in MacOS and forced them onto Linux. Seems to me that the pretty clear difference is in the title of the article; Asahi supports Vulkan 1.3, MacOS does not.

Before steam not a single person could be bothered to get off their asses and do a similar job for any platform.

Before Steam, there was no incentive to develop it. But people most certainly did do the same, job for multiple platforms. Codeweavers wrote several D3D translation layers over the years, WINE had multiple old and slow DX drivers (DirectX-D3DX9) that semi-worked, and even without that you could still run most titles through software acceleration.

And look; if Steam goes rogue and decides to drop support for all platforms but Android Wear, we don't really have to worry that much. The important work is upstreamed in DXVK and distributed by multiple parties, not just Valve. Frankly, the biggest advantage Valve still holds over the community is how smoothly their UI goes from clicking "play" to launching the game. I struggle to imagine a situation where Valve goes full-Monty and the community suffers for it.

kelnos
1 replies
20h30m

Metal was released in June 2014[0], and Vulkan development started a month later, in July 2014[1].

You can interpret that in a few different ways: perhaps Khronos saw Metal's release, went "oh shit, we need to do something", and scrambled to start development of a new API over the next month. Or maybe Khronos (and Valve and others) were already talking about something new for some time before that, and only got a fire lit under themselves after Apple's Metal release. Or maybe the two aren't related at all.

Yes, it took a further two years for any kind of reasonable Vulkan support to be out there, but either way, I think it's a bit disingenuous to say Apple was a trailblazer with absolutely no peer here.

Regardless, the gaming situation on macOS is still... not great. Certainly some game developers have adopted Metal, but overall the main target is still DirectX, and I feel like contemporary/modern OpenGL (ES?) still probably leads Metal. Hell, at this point, Vulkan might have seen more general adoption than Metal has.

[0] https://en.wikipedia.org/wiki/Metal_(API)#History

[1] https://en.wikipedia.org/wiki/Vulkan#History

troupo
0 replies
9h42m

Metal was released in June 2014[0], and Vulkan development started a month later, in July 2014[1]. > > You can interpret that in a few different ways

There are no two interpretations. Metal was released before Khronos even had their "kick off meeting". The official introduction of Khronos didn't happen until 2015. Vulkan 1.0 was released in 2016.

Prior to 2014 there was no Vulkan, and no idea of Vulkan. Sevral companies (AMD among them) tried to peddle their own proprietary APIs as a potential future direction after OpenGL.

And yes, Khronos scrambled to have a modern API after both Microsoft and Apple ended up having one.

Yes, it took a further two years for any kind of reasonable Vulkan support to be out there

No. It took two more years to just release version 1. And even in 2024 it's somewhat laughable to talk about "reasonable Vulkan support" when the major gaming platforms (Windows, Xbox, Playstation) don't support it (Windows supports DX natively, and Vulkan support is left to the whims of GPU vendors). The actual support for Vulkan is declining: https://carette.xyz/posts/state_of_vulkan_2024/

I think it's a bit disingenuous to say Apple was a trailblazer with absolutely no peer here.

The trailblazer was Microsoft. What is disingenuous is to pretend that Vulkan was anywhere at the forefront or that Apple had to pay any attention to it, or that Apple is somehow in the wrong for not supporting it.

Hell, at this point, Vulkan might have seen more general adoption than Metal has.

Of course it doesn't. Because iOS exists, supports Metal, and is a major gaming platform

zbentley
0 replies
20h44m

Maybe so. But they did cave on/rethink decisions around: the MagSafe adapter; butterfly switches; laptop thinness generally (but only a little); onboard HDMI/SD; touchbar controls (for now).

Not saying that means they'll immediately see the light WRT 3D graphics APIs. Just that they aren't universally hostile to revising prior decisions.

troupo
13 replies
21h38m

Really just drives home how big of a mistake it was ignoring Vulkan for the past decade on Apple's behalf, but lord knows they won't admit that until it's too late.

People who keep saying this have surprisingly short/bad memories. And very little idea of the state of the industry.

- Apple already shipped Metal version 1 a full year before Vulkan was even an idea. iPhone, one of the largest casual gaming platforms in the world, is Metal

- Windows and Xbox is DirectX

- Playstation is their own thing (keep forgetting what it's called)

That leaves Android (mostly underpowered and fractured to even run games properly) and Switch who really support Vulkan.

talldayo
9 replies
20h41m

Apple already shipped Metal version 1 a full year before Vulkan was even an idea.

That doesn't stop them from implementing two APIs at once, like every single GPU hardware vendor in existence. But given their avoidance of OpenGL and OpenCL, we should have always assumed Apple's goal was to usurp Open interfaces and replace them with only proprietary options. What else could they intend to signal?

Windows and Xbox is DirectX

Yes. DirectX is covered almost in it's entirety by DXVK. It's harder to find a DirectX game that isn't playable with Vulkan than one that is.

https://www.protondb.com/explore?sort=playerCount

Playstation is their own thing (keep forgetting what it's called)

Yeah, and it keeps biting them in the ass when they have to then backport Playstation-native titles to PC with DirectX. It's a notoriously redundant process.

That leaves Android (mostly underpowered and fractured to even run games properly) and Switch who really support Vulkan.

Well also Windows, Linux, BSD, HaikuOS, Google Fuchsia, QNX, Stadia and Tizen.

And hardware wise you can't forget that Intel, AMD, Nvidia, ARM, Qualcomm and Broadcomm all support it in their GPUs.

robertoandred
7 replies
19h44m

Apple created OpenCL. It was nvidia who made everyone else avoid it.

talldayo
3 replies
18h53m

What does that prove, though? Apple gave up. Ironically, now Nvidia is one of the only remaining companies that supports OpenCL anymore.

Apple is experiencing firsthand what the lack of a CUDA analog does to a company. Whether or not they care is up to them, but clearly the laser-focus on high-performance GPU compute is not doing Apple Silicon any favors in the server space or in the desktop.

robertoandred
2 replies
18h32m

It proves that the idea that Apple avoided OpenCL is ludicrous.

talldayo
1 replies
17h59m

Where does Apple support OpenCL today then?

robertoandred
0 replies
1h30m

It still works on Apple Silicon

pjmlp
2 replies
10h47m

Sure, sure, like Google, Intel and AMD aren't to blame for having made a mess out of OpenCL on their products.

talldayo
1 replies
2h20m

Go ahead, blame literally every single person except the lead maintainer and developer of the project.

pjmlp
0 replies
15m

The reality is that Google, AMD and Intel have more than enough time since 2009, to provide a developer experience, and drivers, that would make people actually use OpenCL instead of CUDA.

Instead, Google created the proprietary Renderscript for Android, while AMD and Intel kept delivering broken drivers, partial implementations of OpenCL, never delivered a proper OpenCL 2.x implemenation with mature C++ support, IDE and GPGPU graphical debuggers.

troupo
0 replies
9h35m

That doesn't stop them from implementing two APIs at once, like every single GPU hardware vendor in existence.

Apple is not a GPU vendor.

Yes. DirectX is covered almost in it's entirety by DXVK.

You mean a non-official non-supported wrapper. No one is stopping you to create such a wrapper for Metal/VK. Oh wait, it exists

Yeah, and it keeps biting them in the ass when they have to

Has nothing to do with the reality of Vulkan support

Well also Windows, Linux, BSD, HaikuOS, Google Fuchsia, QNX, Stadia and Tizen.

The only API Windows supports natively is DirectX. It's up to the whims of the GPU vendors to provide support for Vulkan.

Stadia is a very major player, true. Considering it's dead. TVs as gaming platforms (that's what Tizen is) are non-existent in the grand scheme of things. Neither is Fuchsia. Or HaikuOS.

The only winner here is Linux, but that really only works through the thankless work of maintaining the DX->Vulkan wrappers. Again, nothing is stopping you from doing the same work for Metal.

guipsp
1 replies
16h14m

Apple already shipped Metal version 1 a full year before Vulkan was even an idea.

This is only true if you forget how Vulkan came about.

troupo
0 replies
9h40m

My timing is only a bit off.

Apple released Metal in 2014

Vulkan as a project was started a month later, also in 2014. Officially announced in 2015. First version released in 2016.

pjmlp
0 replies
10h49m

Playstation has two API, GNM and GNMX, low level and high level variants.

Switch does have OpenGL 4.6 and Vulkan support, however if you want the full power of the games console, you need to use NVN instead.

flohofwoe
6 replies
11h50m

Supporting a different 3D API is really not the complicated or time consuming part of porting a game to another platform, especially when the target API is Metal.

The poor game support on macOS is a mix of Apple apathy towards gaming and the low potential sales numbers.

Also, of the few new Vulkan apps being released (a whopping 9 in 2023), most actually only support a single platform:

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

Apple also offers a D3D12 porting toolkit now (basically D3D12 running on top of Metal, same thing like Proton is D3D running on top of Vulkan) which business-wise makes a lot more sense than native Vulkan support since there are many more D3D12 games than Vulkan games: https://developer.apple.com/games/

johnnyanmac
2 replies
8h43m

Supporting a different 3D API is really not the complicated or time consuming part of porting a game to another platform, especially when the target API is Metal.

If you have a graphics programmer on hand, no. The vast majority of indie devs are powerless in that domain, though. I don't see many attempts out there to make it easier for them either.

Maintenance is always the time consuming part, be it simple or complex work. People aren't going to support Linux even if Vulkan theoretically makes it straightforward, because the time needed to maintain it isn't worth the lack of customers. Steam + Proton gives even less incentive to bother. So that advantage doesn't translate to much business value when evaluating DX12 vs. Vulkan.

This is an issue going all the way back to the OpenGL vs. D3D days. Nothing fundamentally changes as long as Microsoft completely swamps the PC gaming market.

flohofwoe
1 replies
8h8m

If you have somebody on the team who was able to write a Vulkan rendering engine, then that same person can also easily pop out a Metal port ... just be careful, that person probably never wants to touch Vulkan again afterwards ;)

Otherwise I would expect that the game either uses a library which abstracts away the differences between the system 3D APIs (shameless plug: https://github.com/floooh/sokol, but also BGFX, WebGPU or AFAIK SDL3 is also getting a cross-platform 3D API), or uses a complete game engine like Godot, Unity or Unreal.

Maintenance is always the time consuming part

This is the only thing that matters, it's not the initial port that's the problem, but the long term maintenance and customer support and that often doesn't make business sense on non-mainstream platforms like Linux or macOS. But a cross-platform 3D API doesn't make any of that easier (you'll still have to struggle with driver bugs for instance, or just plain weird configurations, especially on Linux systems - unless going through Proton which I'm sure works around a ton of compatibility issues and driver bugs under the hood).

talldayo
0 replies
2h24m

it's not the initial port that's the problem, but the long term maintenance and customer support

Which is why I ask; which should we prefer, a native port that Apple will depreciate for some reason or a community-supported translation layer that's based on a reasonable cross-platform standard?

I owned an iPhone, I know that the apps you pay for all eventually break, and instead of fixing it Apple will only tell you to complain to the developer. Compare that to Steam, where I can still play Far Cry 2 and Fallout: New Vegas in perfect emulation, likely for the foreseeable future.

talldayo
1 replies
2h28m

Apple also offers a D3D12 porting toolkit now

Now they do. After 5 years of people begging them for DXVK, Apple gives us... a downstream fork of DXVK retooled for Metal.

I really just feel bad for Mac owners. Like; you could be playing Apex Legends with us, but can't. Like I said, these changes to Asahi will likely make it easier than MacOS to play games on. Who would use MacOS for gaming when Steam Play works out-of-box on Linux? A masochist, I say.

dieortin
0 replies
1h26m

I doubt anyone buys a Mac to install Asahi on it

pmarreck
0 replies
4h7m

the low potential sales numbers

All sales are initially low before a market is grown.

If Apple wanted a machine that was also a great gaming machine, they could have that, and that market would then grow. The fact that they even have a gaming market at all left, shows that the appetite is there. (Of all the machines I have it installed on, Baldur's Gate 3 for example looks best on my Mac screen thanks to the HDR stuff)

DeathArrow
4 replies
11h48m

Really just drives home how big of a mistake it was ignoring Vulkan for the past decade on Apple's behalf, but lord knows they won't admit that until it's too late.

Even if Apple supported Vulkan that doesn't mean AAA games would be ported to Mac soon. AAA require beefy GPUs and Apple silicon isn't going to match Nvidia.

lonjil
1 replies
5h55m

You've got it backwards. Before M1, most Macs that regular consumers owned were incredibly bad GPU-wise. M1 was an enormous upgrade and finally made Mac usable for gaming for the average Mac owner. But years of most Macs being useless for gaming drove the game devs away.

talldayo
0 replies
2h12m

Unfortunately, I don't think simply having a powerful GPU is enough to make people care. The M1 is almost 5 years old now, and I haven't seen a single major games studio go out of their way to target Apple Silicon. If anything, people are giving up on the platform now that OpenGL is more or less entirely broken and Metal is mandatory. Porting to MacOS is like committing to a console ecosystem where things constantly change and you're expected to pay the price. Windows developers don't like that; they want to push one build out and support it for the next decade.

Hope springs eternal, but there's a reason we want Vulkan. Native gaming on Mac is awful; it is quite literally the worst gaming experience you can have between Linux and Windows, both of which can run DirectX games without issue. If we had functioning Vulkan drivers on Mac, we wouldn't be begging and grovelling for games to work; they just would, like on Steam Deck.

sspiff
0 replies
11h24m

AAA can make use of beefy GPUs, but equally it can run on more pedestrian hardware.

If AAA games sold only to those with desktops and high end graphics cards, PC gaming would have died a long time ago. Even today, many games run fine on Pascal era graphics cards, and they certainly run fine on mid range laptop versions of Nvidias 4050 & 4060.

Apples silicon can keep up with those, plus the simpler, less diverse hardware on Mac would probably lead to better optimisation if the market was big enough.

I'm not saying Vulkan is the only thing holding gaming from Apple computers, because I think the control Apple has over software distribution on Mac is also something that scares large publishers away from investing in the platform.

filleduchaos
0 replies
10h55m

I don't think I know a single AAA game released in the past decade that requires a beefier GPU than Apple ships. It would be complete financial suicide for a studio whose development budget runs in the tens and even hundreds of millions these days) to limit their customer base to the relative handful of gamers who have their hands on the latest and greatest graphics cards.

jakogut
3 replies
20h52m

Linux market share is considerably ahead of macOS according to the Steam hardware survey. Just this past month, Linux is sitting at 2.32% compared to macOS at 1.47%.

kelnos
2 replies
20h41m

Genuine question: is it actually reasonable to compare desktop/laptop OS market share with handheld market share? Like... what does that actually tell us? I suppose in the case of gaming it can be useful, since at this point more games are played on Linux (due to SteamDeck) than on macOS. But otherwise, I always get a weird feeling when someone lumps these stats together.

I guess part of the weirdness I feel is when people say "Linux is the most used OS in the world" because of all the Android devices floating around, which is super misleading, since "Linux" isn't really an OS on its own anymore. (Technically it never was, but I'm not one of the "GNU/Linux" pedants, so...) Android and GNU/Linux are very distinct, very different OSes, so it makes no sense to lump them together. "Linux is the most-used kernel in the world" is a more accurate statement, but, again, I'm not really sure what that actually tells us in practical terms.

jakogut
0 replies
20h9m

I think it is actually a reasonable thing to compare. I've had similar thoughts on the Android comparison. Yes, Linux is the most widely used kernel in the world, but that doesn't mean that desktop GNU/Linux is up to the same level of usability. That doesn't mean that desktop GNU/Linux would provide a good touchscreen experience on a tablet. It could, but the entire userspace software stack is completely different.

I think what it does indicate is that the kernel is featureful, stable, extensible, reliable, and a good base to build products and services from.

SteamOS on the Steam Deck is a close cousin of desktop GNU/Linux, purpose built for gaming. It might be a handheld, but it's also a PC. I think the popularity of the device tells us that the compatibility of Linux with Windows software, games especially, is good enough for the average person. It tells us that people are willing to tolerate a bit of a learning curve and some differences to what they're accustomed to so long as the value is there, and 95% of things just work.

It's also worth noting that many Steam Deck users choose to continue using SteamOS, based on Linux, to run their Windows games, in spite of the fact that their device will also run Windows.

exitb
0 replies
17h39m

In this case it seems fine, as SteamDeck is not very distinct from a regular PC and SteamOS is really just a Linux distribution. Anything compatible with SteamDeck can be ran on other Linux installations, as well as other form factors.

duped
1 replies
20h37m

Gaming on MacOS isn't hard, it's just bad.

talldayo
0 replies
20h35m

It's kinda both. I think there's ample demand and opportunity to create a simplified Asahi install script optimized for pushbutton gaming. The biggest constraining factor is disc space.

nox101
0 replies
10h20m

Vulkan is the arguably worst of the modern GPU APIs. It's not all that portable since you have to check for sooo many differences in architecture. It requires the most amount of manual synchronization. It lacks a higher-level shading language (you generally have to pick a library that implements some other higher level language and let it generate SPIR-V for you and pray it works portably).

Except for projects like this, Vulkan really only exists on Linux and Android. It'a not really a thing on Windows. Sure, some games are using it, but they're like 1% or less.

Metal is arguably the best of the 3 APIs, though of course it was easier to do without having any legacy behind it and without being designed by committee.

DiskoHexyl
0 replies
5h15m

Lack of Vulkan support is just one (small) reason gaming doesn't really exist on Mac.

IMO it's more down to Apple's historic view on videogames and software compatibility in general- they are okay with frequently breaking things (like they did with 32bit apps) and expect developers to just constantly accomodate that. With a giant iOS market and its deluge of relatively small free-to-play/service-based games, it's a worthy model for devs to pursue (until the game is unprofitable, and then, in a couple of years, it's delisted as incompatible).

For a more traditional desktop/console style gaming, where a long tail is expected, with little further support, it's a tough proposition to release on a platform that has a miniscule market share AND constantly breaks. Its own graphics API is just a cherry on top, I think

rowanG077
1 replies
1d2h

A ton of games which don't require dxvk are running at 60+ FPS. See https://vt.social/@lina/112524118075585601

Alyssa, the machine that she is, has also been working on improving FEX performance recently.

ricardojoaoreis
0 replies
11h0m

Alyssa did some work for Valve, they might have an interest in FEX for some ARM version of Proton.

Good thing that we can all benefit from it

aurareturn
67 replies
1d1h

I wonder if this effort to add Vulcan to Linux and then translate DirectX in Asahi Linux would impact Apple's dream of landing AAA games on Apple Silicon.

Apple would like AAA developers to port their AAA games over to Metal so that the game has one code base but can run on iPhones, iPads, Macs, and the Vision Pro.

Perhaps Mac gamers will install Asahi Linux in order to play AAA PC titles.

littlecranky67
40 replies
1d1h

would impact Apple's dream of landing AAA games on Apple Silicon

Apple's dream is not to have AAA games land on Apple Silicon - they can do this with Proton-like layer, like they did with GPTK. Apple's wet dream is to have AAA games land in the Apple App Store - not on Steam or Epic Game store. That is why the GPTK effort is only have assed (and the license prevents Valve integrating it into steam directly).

skrrtww
14 replies
1d1h

This is a bit of a tangential rant, so I apologize. But I recently tried to update Death Stranding, the flagship AAA game that Apple landed on macOS and in the App Store. The game itself is 77.5 GB; it had required a little over 150 GB to install. I shrugged that off at the time; they haven't figured out how to decompress on the fly, whatever.

I had about 50GB free on my (1 TB M1 Max) machine at the time of the update, and the App Store told me I didn't have enough free space to update. I balked and looked at the update description, which was just "Various minor bug fixes." The update size was...75 GB. They expect me to re-download the entire game for various minor bug fixes.

(I would "just blame the developer" here, but Apple clearly invested a lot into having this game available on macOS, in the App Store, and got Hideo Kojima to show up at WWDC (a full year ago, remember) and brag about how nice the entire experience is. Some of Apple's engineers probably worked directly on this port.)

It then sunk in that I didn't just need 75 GB of free space. I needed 150 GB. The App Store will completely download and completely decompress the entire game before replacing it. That is the patching process for the game. You need 231 GB free at all times on your machine to have and update a 77GB game.

This is completely insulting given Apple's storage prices, and the fact that the App Store does not let you install apps on an external drive.

Apple clearly doesn't get it. They act like they're nominally putting in the effort, but then it's still just completely half-assed even when things are played exactly like they want.

coldpie
4 replies
1d

There's like, two guys at Apple who care about gaming. Everyone once in a while they manage to convince marketing to say something about it and rope in a couple more devs to half-assedly hammer out some tickets before they can go back to their normal tasking. There's no traction internally to taking PC gaming seriously at Apple.

astrange
2 replies
23h55m

You don't need indoor hobbies when the weather is this nice.

talldayo
0 replies
15h13m

Boldly typed

saagarjha
0 replies
5h55m

It's the warmest first week of June in a while in Cupertino, so I have no idea what you're talking about with regards to nice weather.

MBCook
0 replies
23h39m

From what I’ve heard there are a ton more than 2. But none of them have the power.

bitwize
2 replies
23h46m

I had about 50GB free on my (1 TB M1 Max) machine at the time of the update, and the App Store told me I didn't have enough free space to update. I balked and looked at the update description, which was just "Various minor bug fixes." The update size was...75 GB. They expect me to re-download the entire game for various minor bug fixes.

It is an unfortunate truth that one must now bear in mind, that games are for all intents and purposes enterprise software. They are as critical to profitability for the companies involved as enterprise software. They are large, distributed applications which are planned, budgeted, and staffed much like enterprise software. Accordingly, there is little to no concern for performance except when it's absolutely critical: the rendering pipeline and the netcode, for instance. For things like updates, where it would be easy to make some optimizations to reduce download size, those optimizations will not be taken. So you will redownload the entire game, including all of the uncompressed audio clips, every time someone changes a byte somewhere and it's shipped as an update.

tomovo
1 replies
23h4m

Steam updates are often in the order of kilobytes. Clearly it can be done.

bitwize
0 replies
21h37m

It can be done, and Valve are old-school gamedev bros who clearly are interested in making it happen for games on their platform. But not every shop is like that, and in particular I wince when I contemplate updating a PS4 game...

kmeisthax
1 replies
13h28m

This is a problem even for macOS updates, ever since they moved to the sealed system volume in macOS 11. When you update macOS, it downloads the entire OS and installs it to a separate APFS snapshot. The infuriating thing about this is that the sealed system volume should actually make it easier to provide reliable delta updates, but instead they used it as an excuse to remove them.

And of course Apple's always treated app updates as "download entire new copy of app to separate container and relaunch", ever since day one of the iOS App Store. This too could be handled with APFS snapshots.

I really wish Apple - and the rest of the industry - would stop being so damned allergic to delta updates. It's infuriating knowing how much damned engineering effort, say, Google put into shipping deltas on Chrome, and then everyone else is "just download two copies of every app while you're updating them, bandwidth and storage is free if we don't pay for them".

saagarjha
0 replies
5h53m

I am pretty sure App Store updates are smarter than that. For example Xcode delta installs have taken far less space (though they take a lot longer) if you grab them from the App Store.

crazygringo
1 replies
20h21m

Wow. Truly that's bizarre.

Clearly the App Store was never meant for distribution of 75 GB games, it's clearly meant for mostly <~1 GB packages.

I'm surprised they even allow huge apps like that in the first place, and don't have e.g. a 5 GB hard limit for usability reasons. They should have a limit if they're not going to support patch upgrades.

Who the heck has 231 GB free on their Mac internal SSD? Almost nobody. Why would the developer even distribute this via the App Store at all, for such a miniscule user base?

PokestarFan
0 replies
3h14m

Xcode used to be absolutely massive, being 10GB+ a few years back. They seemed to have done a better job at making it smaller.

trissylegs
0 replies
11h2m

I just rember back when my internet was 512 kbps down and iTunes would have a minor bugfix update over >100 MB which would take over an hour.

I'd just not update iTunes ever.

tracker1
0 replies
23h13m

You need to buy a new mac so you can pay $200 per 256gb of storage.

rched
8 replies
1d1h

This makes no sense to me. Apple does nothing to prevent AAA games on the App Store also being released on Steam. I think it’s more likely that the GPTK license is to encourage developers to make high quality native ports rather than devs checking a box to make their game available on Mac.

coldpie
2 replies
1d

It's because Apple told Steam users to fuck off like 3 times in 5 years (nuking 32-bit support; no Vulkan/OpenGL support; switching to ARM). Users and game devs got the message Apple was sending loud & clear.

robertoandred
1 replies
19h40m

32-bit is the only change that actually broke anything, and it had been deprecated for a decade.

64-bit OpenGL/x86 games work fine on ARM.

scheeseman486
0 replies
8h20m

Will x86 games work in 2 years? Will OpenGL? What about in 3 years? 5? Then what happens to Valve's Apple owning customers purchases?

jorvi
1 replies
1d1h

Apple killed support for legacy 32-bit applications a good while back, which killed support for virtually every Mac game port.

vanchor3
0 replies
20h16m

The funny thing is most games in my library say they won't run on macOS because they're 32-bit applications, and they won't show up in my library when filtering by "Mac". But they all run perfectly fine, so they're obviously 64-bit. I think I heard once that they all default to 32-bit unless the developer says otherwise...

vanchor3
0 replies
20h11m

I'm sure it doesn't make a big difference but the issue with this is it doesn't count Mac users using CrossOver/Whisky because they get detected as Windows users, while Linux users with Proton are reported as using Linux.

nozzlegear
0 replies
1d

I play games on my Mac, but I don't use Steam. I just play World of Warcraft which is a native Apple Silicon game, and a few other games that don't require Steam.

babypuncher
5 replies
1d1h

Apple's wet dream is to have AAA games land in the Apple App Store

This is why their efforts are largely doomed.

I'd love to play more AAA games on my Macbook, but too many of them require a separate purchase from the App Store to make that happen, rather than just putting the Mac versions on Steam alongside the Windows version.

If you're going to make me choose between playing a game on my laptop and playing it on my gaming desktop, I will choose the desktop every single time. It would be nice to take more of those games with me when I travel, but it's not a frequent enough use-case for me to give up all the benefits of real PC gaming.

littlecranky67
2 replies
1d1h

This is why their efforts are largely doomed

I'm not as certain about that as you are. I think there are - as always - different streams withing that mega corporation. It is probably sales-oriented people wanting nothing but AAA games on the App Store and be okay with the Mac not being a major choice for games if that doesn't happen. The other stream is probably more enthusiastic (especially with the Apple Silicon being "enough" gaming machines for 1080p@60) and wants to bring gaming over - that is probably the stream that made GPTK happen and give a licensing exception to crossover to be able to integrate it in their department. I'm in the later department, hoping we will see a proton-like GPTK that can run my steam library.

babypuncher
1 replies
1d1h

hoping we will see a proton-like GPTK that can run my steam library.

I would absolutely LOVE this! I also know a lot of people who would be a lot more interested in buying a Macbook if this were a thing.

littlecranky67
0 replies
1d1h

Well regarding the Macbook/Laptop case vs. Desktop: With me typing this on the MacMini M2 base model (8GB/256GB) retailed at 650€ I can assure you, it is a nice gaming machine hardware-wise. Not for latest and greatest AAA games of course, but I played through all the Tomb Raider reboot games on this machine (using Rosetta2 as they are non-native on Steam) on High details with 1080p. Now the major issue is software, there is just not enough games available. I do use Heroic+Crossover Wine to run some other games, but it is just finnicky and only for the pro user - not average casual gamers.

Saying this, Apple could launch a 999€ Mac Mini with focus on gamers with a custom M4 design soon, if they had a proper Proton-like layer. Heck, size & noise wise, the Mac Mini beats the current PS5 and Xboxes. But they only treat GPTK as a solution for developers, not gamers. And I highly suspect, this is only due to the fact that they won't get any percentage from games sales, as Steam is the dominant player here.

behnamoh
1 replies
1d1h

What do we do as Apple users stuck in this ecosystem whose main goal is to extract more money from our pockets? I hate Windows with all my gut but at least I had a sense of freedom about the software I wanted to install on Windows, including games.

On Mac, I'm constantly reminded that beyond this facade of user-friendly UI and nice visuals, there's a greedy company whose market cap is $3T but doesn't give a flying f* about the end-user because it wants to make even more money.

bsder
0 replies
23h18m

What do we do as Apple users stuck in this ecosystem whose main goal is to extract more money from our pockets?

Leave ... the ... ecosystem.

This is the whole point of things like Asahi Linux. Take advantage of the hardware and escape from the software.

If all the developers who slave over Apple devices spent 10% of their time improving the experience on something else, 24 months later Apple wouldn't have a market.

I left. I got tired of fighting bugs in macOS given that Apple clearly no longer gives a damn about macOS.

I just bought my second Lenovo Carbon X1 after leaving Land-Of-The-Fruit. This one is about $1700 + a Saumsung 4TB SSD. Note: I can actually upgrade the SSD. It has 32GB of RAM for half the price of anything equivalent in macOS. The OLED display is right about the equivalent macOS resolution, and it's a matte display. It has a useful set of ports--a goddamn HDMI port as well as 2 USB-C and 2 USB-A ports.

And Lenovo's external dock actually freakin' works.

Yeah, it probably doesn't get the performance or battery life as an M3. Given that I didn't notice on my previous Lenovo vs an M1/M2, I'm not likely to notice this time either.

And, as a "bonus", I can run an actual Windows install if I absolutely must.

snarfy
2 replies
1d1h

Your comment puts it very succinctly.

They don't care about your gaming experience on Mac. They care about money.

I wish they weren't so short sighted here. They can't see through the trees that maybe they won't make money selling games through the app store, but they would make money selling more Macs.

rched
0 replies
1d1h

Seems like the opposite is true. If their primary motivation was more App Store sales why not allow GPTK games only through the App Store?

MBCook
0 replies
23h37m

They didn’t really care about it before the Mac App Store either.

The OS and its libraries just aren’t designed for high performance gaming the way MS has put time into that on Windows.

They have Metal, which is supposed to be nice. But that’s their Direct3D. Where is all the other DirectX equivalent?

From what I’ve heard anecdotally that seems to be a big part of the problem. It’s not just that they don’t have Vulcan (which I think is a red herring). Or the GPUs were abysmal (they were on most models before Apple Silicon).

There’s no whole-picture. Just pieces.

AltruisticGapHN
2 replies
1d

I don't get it. They already make a ton of money on mobile games - why not embrace Steam and Proton on their platform? What's the money in AAA games on their platform?

edit: this is to say if they had "wet dreams" about selling AAA games on Mac, we'd have seen the tides moving a long time ago.

viraptor
0 replies
20h27m

Buying from Steam doesn't give them the appstore cut. And nobody buys Macs for gaming, so it doesn't drive hardware sales either.

_carbyau_
0 replies
17h58m

What I don't get is that games compete in the attention market and are a big money industry next to movies and TV.

Apple is happy to produce its own movies and tv shows but not AAA games?

Or maybe they have and I simply didn't see that blip, I am honestly not in sync with Apple gaming world.

Almondsetat
1 replies
1d1h

What has proton got to do with x86 -> ARM ?

littlecranky67
0 replies
1d1h

x86 -> ARM is already done by apple (rosetta2). What they need is a wine layer to mimmick the Windows API to allow a large amount of existing games to run on macOS without the devs porting. Which DOES exist, it is called crossover (and uses wine and GPTK). But it is a 3rd party company.

jppittma
0 replies
16h51m

The only way I can see that happening is with an EEE model. You'd go grab all of the non-steam publishers and come up with a standard format that'd mean that studios can push to every platform in a standardized way, then bank on nobody bothering to install steam because the app store already has all of the games you want, and it's installed by default.

aurareturn
0 replies
17h1m

  Apple's wet dream is to have AAA games land in the Apple App Store - not on Steam or Epic Game store.
This is implied already when I said Apple wants the AAA game to be on iPhone and iPad. By definition, the game has to be on the App Store.

rowanG077
19 replies
1d1h

If Apple truly wanted that they could simply implement Vulkan.

galad87
18 replies
1d1h

Why Vulkan? Let's implement DirectX directly and call it a day.

babypuncher
12 replies
1d1h

Vulkan is how Direct3D is implemented on non-Windows operating systems, thanks to DXVK.

galad87
11 replies
1d1h

I know, but why make a Direct3D wrapper on Vulkan when in the end you are going to run only Direct3D games anyway.

kbolino
9 replies
1d1h

Direct3D means only Windows and Xbox. Vulkan means everything non-Apple except Xbox and PlayStation. It's not everything, but it's a larger base.

galad87
8 replies
1d

What's larger than Windows + Xbox + Playstation for AAA games?

kbolino
7 replies
22h40m

No single 3D API is capable of supporting all 3 of those platforms. However, if those are the only 3 you're concerned with, then Direct3D gets you farther (Windows+Xbox) than Vulkan (Windows only). You're still going to have to write/use something different for PlayStation (which has its own custom API).

The two major platforms that favor Vulkan are Android and Switch, but the former is in the "mobile" category rather than the "desktop/console" category and few games overlap both categories.

But really, Asahi Linux on M1 Mac is about as niche as you can get, so broad hardware support for native APIs isn't really relevant, and I don't think AAA games are necessarily what's meant to be supported either, since they generally won't work for other reasons (can't install x86-64 Windows kernel driver DRM/anticheat on an ARM Linux machine).

rowanG077
6 replies
21h44m

AAA gaming is THE driving factor for getting Vulkan on Asahi. There really are only a tiny subset of games that require a kernel anti cheat. Let alone the wealth of single player games.

kbolino
5 replies
21h22m

I'd love to hear about all these DRM-free single-player AAA games. If you're talking about older games, then maybe we're just talking past each other; I assumed we were talking about recent AAA games.

rowanG077
2 replies
19h57m

They don't have to be DRM-free.Here you can play all of these on linux: https://www.protondb.com/explore

Highlights include Elden Ring, Baldurs Gate 3 and God of War.

kbolino
1 replies
4h32m

I upvoted for the link, which is useful to me, but I'm not sure this means Steam and all of those games will be able to run on Asahi/M1.

rowanG077
0 replies
3h57m

No one can look into the future. But Fex + Vulkan definitely have the goal of being able to run those games.

babypuncher
1 replies
2h28m

Recent AAA games absolutely run on Linux using Proton. DRM isn't really a concern. The biggest and most successful DRM vendor, Denuvo, even goes out of their way to make sure their product does not interfere with Proton compatibility.

It's pretty rare for a new game to come out and not be playable on the Steam Deck within a week if not on day 1. And when that does happen, it's usually a PvP multiplayer game with kernel-level anticheat.

kbolino
0 replies
1h26m

I'd assume Denuvo DRM works on Linux x86-64 because the company has made it work on that platform. I'd be surprised, with FEX in the middle, if it doesn't get bent out of shape running on ARM: either flagging itself as having been tampered with, or the game. Maybe the company also has a solution for ARM support though.

I do think the question of "why Vulkan" has been thoroughly answered though: 1. DXVK means Direct3D->Vulkan translation already exists (but not the other direction) and 2. Proton already proves that Vulkan gets you most AAA games (with the exceptions having nothing to do with the 3D API).

babypuncher
0 replies
1d1h

Because DXVK already exists, and you do still want to run Vulkan anyways. There are AAA games out there using it instead of Direct3D. Natively re-implementing Direct3D APIs would be a tremendous amount of work for little or no real benefit.

treyd
1 replies
1d1h

Microsoft would never allow them to use the trademark.

jeroenhd
0 replies
23h43m

While that's true, I don't think they'd need the trademark. They can call it Apple StraightforwardY, duplicate any trademarked APIs and redirect the old ones to their own methods for "compatibility". The Oracle v Google lawsuit proved that APIs can be implemented, even by competitors.

I see even less incentive for Apple to concede defeat and implement Microsoft's API than for them to port Vulkan. After all, they've already shipped a graphics engine that a handful of games have ever used with their OS so they have experience!

jakogut
1 replies
20h32m

There are already high quality implementations of every version of Direct3D released over the past couple decades built on top of Vulkan.

Writing a Vulkan driver is purportedly a much easier task than for higher level graphics APIs like Direct3D/OpenGL.

andrewmcwatters
0 replies
2h56m

Direct3D 12 is basically Vulkan.

rowanG077
0 replies
21h49m

Why would apple Implement an API they have zero control over? That's just stupid. In contrast Apple already is a member of khronos and you get DirectX for free anyway if you have Vulkan due to dxvk. There are only downsides to implementing DirectX.

wmf
2 replies
1d1h

Apple already released the Game Porting Toolkit.

talldayo
0 replies
1h49m

...which, unlike DXVK, cannot be redistributed with your app to make it playable on MacOS. So, by definition, Game Porting Toolkit is a mandatory extra-step for Mac users when Linux and Windows users press the little green "Play" button on their screen.

mort96
0 replies
12h3m

For some reason I'm completely unable to find its license through Google (I swear I used to be able to find this sort of stuff with search engines...); but I remember it being extremely prohibitive, to the point where even using it for personal use to play Windows games is illegal. It's only for use by game developers as a tool to help them on the road to port their games to macOS.

AltruisticGapHN
2 replies
1d

Pretty much, Asahi Linux could become the new Bootcamp for Mac users who dual booted to play games.

FWIW I played Diablo II Resurrected on a M1 with "Whiskey". I was quite impressed that I was able to play a native Windows game just like that. It doesn't work anymore just because a stupid Blizzard launcher update now crashes and prevents starting the game.

I also ran EverQuest II admittedly an old DX9 game but still the game ran beautifully on a M1 mac mini at 1440p.

Linux Asahi may help also with older x32 titles like Guild Wars.

thehias
0 replies
22h13m

Just buy Crossover, then Diablo runs fine on MacOS again!

Tehnix
0 replies
7h4m

I've been playing Diablo 4 and Diablo II Resurrected on Crossover ever since Whisky didn't work with Battle.net anymore. It's been working great tbh!

delta_p_delta_x
25 replies
23h44m

Hacker News regularly makes me feel very stupid, and none more so than blog posts by Alyssa Rosenzweig.

I couldn't even write an engine that used Vulkan in six months, nor a software rasteriser; meanwhile, Alyssa wrote an entire compliant driver on a non-native operating system running on locked-down hardware in one month flat.

What am I doing with my life?

EDIT: I point this out because I'd eventually like to write GPU drivers too, having been fascinated by video games since I was like three.

wmf
4 replies
23h27m

You're making wrong comparisons is what you're doing. If you had already written N game engines, could you write a new one in a month? Yes, right? Alyssa didn't spring from the head of Zeus fully formed; she has been developing GPU drivers for years. Pick something you want to work on and work on it for years.

tcmart14
3 replies
23h21m

Yes, definitely want to back this up. Alyssa is definitely a really skilled and competent engineer. But she also has years of domain knowledge she has built up. That isn't to knock down her skill, but more of, don't let it demotivate it you because it too also took Alyssa time to get where she is.

fermuch
2 replies
23h19m

She is also great at communicating her advancements, which is a greatly useful skill to cultivate.

tcmart14
1 replies
23h5m

That is something I was just thinking about a few moments ago. I've haven't watched any of Hector latest stuff if he is still streaming. But between Hector, Alyssa, and Asahi Lina, they all 3 are pretty motivated and pretty excited to share. Which is great and something I wish we had more of. It helps to demystify these systems some. For many, GPUs and graphics APIs are just black boxes of magic and it can be hard to get past that. But content like this helps to remove the black box and make it more approachable.

TheAmazingRace
0 replies
19h0m

More like just Hector and Alyssa. Asahi Lina isn't a real person, but more of a mascot.

__madness
3 replies
22h1m

I sometimes feel like her success is driving me into madness, I feel like Salieri looking at Mozart when I look at her work.

Here is the Alyssa timeline:

* She started programming at ~3 with MIT Scratch. Her Father introduced it to her, he works at Intel and is a very successful person.

* I think around age 11-12 she knew C very well, worked on some low level networking stuff for games, she wanted to make an MMO.

* At 12 she made a project to convert LLVM IR to MIT Scratch.

* She was involved with libreboot, not sure to what degree.

* She was 15 when she worked to the open source RPI firmware.

* Interned at FSF

* I think she was ~16 when she developed the Panfrost GPU driver.

I can't help but wonder how my life would be if I was a native English speaker. Lived in USA and had a great father and mentors like hers. I gave everything to programming, everything I have to give. Wonder if I am hitting the limits of my nature or just had worse nurture.

internet101010
0 replies
21h6m

It's like being born a Gracie and starting jiu jitsu before you can walk. Of course you are going to be proficient in that field at a young age due to being taught by an expert at a time when the mind is most malleable.

darkwater
0 replies
10h4m

She probably was born with already very good genetics for her brain to grasp those concepts + bespoke tutorship from a very competent tutor very early on, that's a winning combination (at least concerning low-level programming)

erichocean
2 replies
23h24m

What am I doing with my life?

Not working on GPU drivers for third-party hardware?

These blog posts are fun, but they're in the same genre as porting game boy emulators.

a1o
1 replies
23h13m

It takes more lines of code to draw a triangle in the screen with Vulkan than it takes to write a Gameboy emulator that can play Pokemon Blue. Vulkan is a modern stack, Gameboy isn't.

htatche
1 replies
22h37m

Maybe you’re just enjoying it rather than spending all your waking time writing code?

anyfoo
0 replies
21h57m

That's a big assumption. Alyssa may very well not spend all her walking time writing code (setting aside the implication that writing code is not "enjoyable" for now).

Feynman was a very successful physicist. A nobel price medalist, among other things. He very famously was also someone who enjoyed a life outside of physics a great deal.

Paul Erdős, on the other hand, did at least outwardly seem to have spent most of his life focused on doing mathematics. And nobody can convince me that he did not enjoy his life as well...

Osiris
1 replies
22h44m

I often also feel imposter syndrome. But it's also good to realize that some people are just better at things than others, others have more free time, more motivation, more experience, etc.

Don't let other people's success bring you down.

Of course I've been dealing with imposter syndrome my whole life because my older brother is a genius and it's taken me my whole 44 years of life to try not to compare myself to him.

speedgoose
0 replies
21h19m

Some people are simply better in most aspects. And it is fine.

zeeveener
0 replies
23h24m

You're living it the best you can with what you have. As the other commenter stated, you are making unfair comparisons. Focus on comparing your tomorrow self with your today self. As long as that comparison trends in the right direction, you're doing well.

thegrim33
0 replies
22h36m

One complicating factor is also there's a huge range of time required for different levels of quality.

Something that's quickly hacked together with limited error handling, limited security, limited flexibility/reusability, vs. something very high quality and enterprise quality.

phkahler
0 replies
23h13m

> Alyssa wrote an entire compliant driver on a non-native operating system running on locked-down hardware in one month flat.

Well if it makes you feel any better, remember that she has spent a few years doing very in-depth work on other graphics drivers for this hardware so she knows the hardware, shader compilers, etc inside and out. There is also a full test suite for Vulkan and existing driver code for other hardware to start from. Nevertheless, you're still seeing a great programmer at the top of their game :-)

masto
0 replies
21h50m

You think you feel stupid, I don't even know what a Honeykrisp Compliant Vulkan is. Sometimes Hacker News makes me wonder if I've had a stroke.

lemoncucumber
0 replies
22h34m

I couldn't even write an engine that used Vulkan in six months, nor a software rasteriser; meanwhile, Alyssa wrote an entire compliant driver on a non-native operating system running on locked-down hardware in one month flat.

Apple Silicon Macs are explicitly not locked down, it's just that the hardware is totally undocumented. This means that there's no jailbreaking necessary, just a lot of reverse engineering (which is still very difficult of course).

From https://asahilinux.org/about:

Apple allows booting unsigned/custom kernels on Apple Silicon Macs without a jailbreak! This isn’t a hack or an omission, but an actual feature that Apple built into these devices. That means that, unlike iOS devices, Apple does not intend to lock down what OS you can use on Macs (though they probably won’t help with the development).
jamesu
0 replies
23h1m

Writing an engine from scratch is debatably more complicated since you need to do a lot of guesswork around what capabilities you actually need and how badly the artists and gameplay programmers will break everything - assuming your not doing it all solo.

braiamp
0 replies
23h12m

No programmer ever work from zero. If you see the header files for the new drivers, most of them have multiple copyright information. The files themselves were "stolen" from other good drivers to reduce the amount of code that has to be rewriten and the potential bugs that could be avoided by simply reusing.

SushiHippie
0 replies
35m

I couldn't even write an engine that used Vulkan in six months

There is now a blog post on the frontpage where someone wrote a game engine using Vulkan in 3 months ;)

https://news.ycombinator.com/item?id=40595741

Sparkyte
0 replies
22h58m

Experience is everything.

tombert
11 replies
1d

A very large part of me is annoyed that Apple didn't open source Metal before Vulkan was released. OpenGL definitely was annoying to work with, but Vulkan is impossible for the average user to do anything with; drawing a spinning cube takes several hundred lines of code, which I've written and I still don't really understand!

I realize that Vulkan isn't meant for a "humans" to write, it's basically meant to be a target, and that's fine, but it annoys me that you get people on forums that say "learn Vulkan instead" when people ask for help with OpenGL.

Metal is substantially more fun to write than OpenGL or Vulkan; I haven't measured any performance stuff on it, but it certainly feels fast enough, and I've been able to do basic graphics experiments with it in way less time than I was ever able to accomplish with OpenGL or Vulkan.

Still, whether or not it annoys me that Vulkan has become the new standard, portability of the standard is important, so obviously this announcement is a godo thing.

hgs3
6 replies
1d

Please don't misinterpret this as gate keeping, but Vulkan is designed by and for professionals (not hobbyists). It is certainly not a rapid prototyping tool. Vulkan and OpenGL aren't comparable because Vulkan isn't merely a graphics API, but rather it's a low-level GPU API. For example you can use Vulkan in place of CUDA for running highly parallelized computations on the GPU (no graphics implied).

tombert
3 replies
1d

Yeah, I know, that's why I mentioned it being a target. I realize it's meant to be used for extremely low-level stuff. Which is fine, I don't get annoyed at x86_64 assembly being difficult to write.

As I said, the thing that bothers me is when people act like Vulkan is a replacement for OpenGL (presumably because they've never actually written either and they just saw some YouTube demos), and it really isn't, or at least that's an incomplete picture. It's a replacement for OpenGL in the same way writing JVM bytecode directly is a replacement for Java; they fundamentally do the same or similar things, but one is sort of categorically different in its goal.

I do wish that there was a more consumer-friendly API announced in addition to Vulkan though; I'm fine with replacing OpenGL with something newer and better-fitting for newer cards, but that's not what we got. That's why I was trying to say that I was annoyed that Apple didn't open source Metal, because I feel like it really could have taken that role.

Also, while I'm aware that Vulkan doesn't inherently imply "graphics", I would also like to point out that CUDA and rocM are also considerably easier to write than the Vulkan equivalents, at least in the little examples I played with, though I will acknowledge that I felt Vulkan was better than OpenCL.

hgs3
1 replies
23h34m

I would also like to point out that CUDA and rocM are also considerably easier to write than the Vulkan equivalents

I agree that Vulkan has more boilerplate, but I think that's because Vulkan is an open standard and makes fewer assumptions which means the API has more ceremony. For example Vulkan might be implemented for custom embedded hardware; its design helps give the manufacturer more leeway. CUDA and ROCm were designed by Nvidia and AMD for their own hardware and so they can bake in low-level assumptions which means a more streamlined API.

tombert
0 replies
23h29m

Well ROCm is more or less designed to be portable between both; that's not strictly true but it's fairly similar to CUDA so I don't know how much of that boilerplate is reduced by the fact that it's AMD specific. Your point is fair though; Vulkan kind of runs on almost-literally everything made in the last nine years or so, so it can assume basically zero about any kind of underlying OS stuff.

Still, Vulkan has convinced me that I have no desire to work that low-level of GPU programming, as I had zero fun playing with it. I guess I like having one layer up of abstraction; I'm happy enough to write CUDA, and I'm happy enough to write anything higher level than that.

garaetjjte
0 replies
20h13m

I do wish that there was a more consumer-friendly API announced in addition to Vulkan though

Maybe WebGPU could be that?

flohofwoe
0 replies
9h36m

but Vulkan is designed by and for professionals (not hobbyists)

Vulkan is designed by committee, and that's its single biggest problem (and this was also the single biggest problem of OpenGL).

andrewmcwatters
0 replies
3h1m

Please don't misinterpret this as gate keeping, but Vulkan is designed by and for professionals (not hobbyists). It is certainly not a rapid prototyping tool. Vulkan and OpenGL aren't comparable because Vulkan isn't merely a graphics API, but rather it's a low-level GPU API. For example you can use Vulkan in place of CUDA for running highly parallelized computations on the GPU (no graphics implied).

This is bullshit and it doesn't mean anything. In the days of OpenGL, you used the same initialization code regardless if you were a "professional" or a "hobbyist." Code is code.

It especially doesn't mean anything because people use CUDA for CUDA, and want to use Vulkan for graphics because OpenGL has been discontinued.

dlachausse
3 replies
22h53m

I wonder how feasible a Metal compatibility library wrapped around Vulkan would be? That way you could use Metal on other platforms.

Also, what is the best resource for learning Metal if all you know is some OpenGL 1.x from the old “Lego” book?

tombert
2 replies
21h47m

I wonder how feasible a Metal compatibility library wrapped around Vulkan would be?

Sort of an inverse of the MoltenVK project? I don't see any reason why that would be infeasible other than "no one really wants this but me".

Also, what is the best resource for learning Metal if all you know is some OpenGL 1.x from the old “Lego” book?

To be clear, I am not a graphics person, I'm a dude who dicks around with graphics occasionally to play with some kind of more graphical algorithm I read about, but I really don't know what I'm talking about.

That said, I went through this book, It's good enough: https://a.co/d/b3yjPMp

A former coworker of mine also wrote this one if you're interested in iOS game dev, though I have not read it so I cannot speak to its quality: https://a.co/d/c99oE0Q

dlachausse
1 replies
20h27m

Thanks! I always wanted to learn Metal, but it doesn’t seem like there are many resources on it other than Apple’s website.

tombert
0 replies
18h30m

I also think FNA is pretty cool as well. It’s kind of “mid level” instead of low level, more or less like a light Direct3D. I think MonoGame is supposed to be comparable but I haven’t used it.

jandrese
5 replies
1d1h

    Their shaders contain a peculiar construction:
    
    if (condition) {
       while (true) { }
    }

    condition is always false, but the compiler doesn’t know that.
What is the purpose of this other than to be a poison pill for people writing compliant shader compilers?

nsajko
1 replies
12h23m

The purpose of the construction could be to inform the compiler of the fact that the condition is always false, so as to enable the compiler optimizer more.

Take a look at these features in C++, LLVM or Rust if you're not familiar with the concept:

* https://en.cppreference.com/w/cpp/utility/unreachable

* https://en.cppreference.com/w/cpp/language/attributes/assume

* https://en.cppreference.com/w/cpp/memory/assume_aligned

* https://llvm.org/docs/LangRef.html#unreachable-instruction

* https://llvm.org/docs/LangRef.html#llvm-assume-intrinsic

* https://doc.rust-lang.org/std/hint/fn.unreachable_unchecked....

* https://doc.rust-lang.org/std/hint/fn.assert_unchecked.html

The infinite loop is effectively an unreachable instruction (reaching it is not allowed), and an unreachable instruction behind a branch effectively becomes an assume instruction.

SomeoneFromCA
0 replies
6h57m

No, it cannot, as while (true) {} is not UB and should not be optimized out. EDIT: oops, yes you are right, it is not c++ after all.

zamadatix
0 replies
1d1h

Isn't the main point of tests to be poison pills for people writing compilers so they can ensure any shaders passed to the compiler don't break it? I.e. it's not that the specific code is useful as is in practice but if a chunk of a shader ends up functionally simplifying to something like this in a particular instance your shader compiler still needs to handle it right even though it could be written better at that point.

tombh
0 replies
1d1h

Is this how shaders "panic"?

JakaJancar
0 replies
23h1m

Maybe an edge-case in some codegen?

drpossum
5 replies
1d1h

Can someone explain how this relates to MoltenVK? This just removes the need for it as it's a native driver?

Tiberium
1 replies
1d1h

MoltenVK is an implementation of Vulkan based on Metal so that it can be used on macOS to run Vulkan applications. Asahi Linux is an in-development Linux distribution to make Linux compatible with Apple's M series processors. This specific blog post is about making GPU-accelerated Vulkan work on Asahi.

AltruisticGapHN
0 replies
1d

And I think the point is they will then be able to support DXVK to run Direct3D games.

rowanG077
0 replies
1d1h

MoltenVK translates metal to vulkan. Metal is the main graphics API on OSX (and iOS). This is a native vulkan implementation on linux. The blog post itself mentions that as well. This can't run directly on OSX so it won't remove the need for MoltenVK.

pantalaimon
0 replies
1d1h

This is about Vulcan on Linux, not macOS

gary_0
0 replies
1d1h

This is for Vulkan on Asahi Linux on M1 Mac hardware. MoltenVK provides Vulkan on top of Metal on MacOS.

machine_coffee
3 replies
22h4m

Something crashes, it's _never_ a compiler bug ...

April 16 Oh, it actually is a compiler bug!

Can confidently say I've never experienced one in my career, but at some level of abstraction I guess it's less rare to find them.

anyfoo
1 replies
21h53m

It's never a compiler bug, and it's definitely never a CPU bug.

Unless you're a low level kernel developer, then it's both!

(Jokes aside, it's still much, much more often not than it is, but it definitely does happen.)

mort96
0 replies
11h59m

I mean she wrote the compiler didn't she? At least the register allocator part

"It's never a compiler bug" doesn't really apply when it's your own work-in-progress compiler you're testing...

exDM69
3 replies
22h51m

If you're unfamiliar with Vulkan 1.3 but are interested in low level graphics API work, you should check it out. It is a game changer and a huge difference to Vulkan 1.0.

Once past the initial hurdle it's a pleasure to work with, with all dynamic states and no render pass up front set up, it is much easier to work with, even easier than OpenGL (which I've used for 20 years). Graphics programming is fun again.

It's available, or at least most of the features, on all desktop platforms with GPUs less than 10 years old give or take as long as drivers are up to date.

Unfortunately there is no "reasonable defaults" framework to get you off the ground but there are a lot of useful helper libraries for several languages.

HexDecOctBin
1 replies
22h14m

Is there any tutorial/documentation to get started with Vulkan 1.3 specifically? Last time I looked, all I found was a hodgepodge of techniques using old and new methods haphazardly in various combinations. Though that is exactly how OpenGL used to be, so maybe the apple (heh!) doesn't fall far from the tree. Well done, Khronos...

masfoobar
0 replies
8h59m

Thank you -- I appreciate this comment.

I have "dabbled" in OpenGL for 20 years. I am not a pro games programmer, but I do make 3D content for fun in my spare time.

One thing I have not had time is converting over to Vulkan. I guess I just need to pass the init and setup hurdle. I do think once I pass that, there is no going back (to OpenGL)

Point is - your message was a little inspiring.. kinda triggered a part of my brain to do it.

Have a good day.

whitehexagon
2 replies
1d1h

Amazing, I'd only just updated for ES 3.2 support. It feels like my M1 was built for Asahi! although to be fair I only booted macos once on it, probably during install, or by mistake!

Anyway great work! and nice to have these detailed updates.

Are any browsers supporting 'zero copy rendering' or still layers and layers of compositor stuff going on? I seem to recall also getting stuck with webgl2 transform feedback triggering read backs.

zamalek
1 replies
17h55m

Is it possible to remove MacOS entirely? This has me considering a mini for travel.

IntelMiner
0 replies
16h6m

MacOS is still needed for the various firmware updates and other components. But the Asahi installer seems to shrink it down to about 30GB which is acceptable

adastra22
2 replies
1d1h

Is any of this usable from within a VM? I dev on macOS and generally like it, but run a VMware image of Ubuntu for testing things. I do 3D graphics apps, and I’m not sure how good VMware’s pass through is. Is the Apple Silicon GPU virtualized in the VM? Could I run this distro and get better graphics performance?

thehias
1 replies
22h11m

No you have to install native. Also Parallels is way better than VMware, if you want good 3D performance inside a Windows/Linux/MacOS VM on MacOS.

adastra22
0 replies
8h32m

Parallels requires a separate license per machine. That restriction alone is a permanent non-starter for me.

ekianjo
1 replies
1d

why use Fex instead of Box86?

rowanG077
0 replies
23h1m

Box86 can't run on apple silicon. There is no 32 bit support.

dlachausse
1 replies
1d1h

It begins with a text.

Faith… I think I want to write a Vulkan driver.

Her advice?

Just start typing.

I love this part. It is such great advice and it applies to so many things that we want to do in life, but never start because we become paralyzed with fear due to what seems to be an insurmountable task.

vramana
0 replies
22h35m

Exactly me feelings. I am inspired by the work Asahi Linux team publishes. As a full stack developer, I feel very very distant from this part of the stack. Everything looks like greek and latin. Reading this post gives me hope. May be I can someday understand how the drivers are written, I leave my fear and start writing and reading code.

signa11
0 replies
15h56m

this:

'''

April 16

The tests for “descriptor indexing” revealed a compiler bug affecting subgroup shuffles in non-uniform control flow. The M1’s shuffle instruction is quirky, but it’s easy to workaround. Fixing that fixes the descriptor indexing tests.

'''

is just bonkers !

mschuster91
0 replies
19h30m

Some formats are implicitly reordered. Common “BGRA” formats swap red and blue for historical reasons.

JFC that brings up nasty memories dealing with OpenCV. One might think this kind of stuff would be solved by now and people would have converged on something sane, but no, it isn't...

gigatexal
0 replies
1d1h

When I grow up I want to be half as competent as her at programming. Holy smokes. Bravo.

TheAmazingRace
0 replies
18h56m

Alyssa strikes again with some amazing coding wizardry. I don't know how she does it, but I'm glad she's fighting the good fight.

RecycledEle
0 replies
20h22m

I assumed this means a ULA rocket would be transported down a British highway.