Live data from Hacker News

Vulkan1.3 on the M1 in one month

rosenzweig.io

321–330 of 372 posts

Re: Vulkan1.3 on the M1 in one month

#321

Earlier quoted context omitted.

>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 compl…

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…

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

Re: Vulkan1.3 on the M1 in one month

#322

Earlier quoted context omitted.

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

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

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

Re: Vulkan1.3 on the M1 in one month

#323

Earlier quoted context omitted.

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 spen…

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

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

Re: Vulkan1.3 on the M1 in one month

#324
post #267

Earlier quoted context omitted.

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

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

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

Re: Vulkan1.3 on the M1 in one month

#325
post #306

Earlier quoted context omitted.

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 iP…

> You want to make a AAA game, you probably don't go Metal if you want enough market coverage to recoup your costs Likewise you don't care about Vulkan. You care about DirectX and whatever Playstation has

> You care about DirectX

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

What am I missing here?

Re: Vulkan1.3 on the M1 in one month

#326
post #258

Earlier quoted context omitted.

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

Only if we don't care about those using devices where OpenGL ES is still more stable, with less buggy drivers. If you only care about latest Android versions, and Samsung and Google phones, sure go Vulkan.

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

Re: Vulkan1.3 on the M1 in one month

#327
post #302

Earlier quoted context omitted.

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

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.

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.

Re: Vulkan1.3 on the M1 in one month

#328
post #260

Earlier quoted context omitted.

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

It is still Metal, regardless.

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.

Re: Vulkan1.3 on the M1 in one month

#329
post #278

Earlier quoted context omitted.

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 wh…

> 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 n…

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

Re: Vulkan1.3 on the M1 in one month

#330
post #308

Earlier quoted context omitted.

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 Lightni…

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.

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

Post reply on HN