Apple basically just released Proton for Mac

[WolframaticAlpha]

Apple should just put Vulkan on the Mac. It is quite funny that the only way to run Doom eternal on the Mac is by running the Switch version through an emulator.

[Obioban]

1 hour ago, WolframaticAlpha said:

Apple should just put Vulkan on the Mac. It is quite funny that the only way to run Doom eternal on the Mac is by running the Switch version through an emulator.

I'm not saying they shouldn't, because it would certainly be more performant if Apple did it, but that is currently one of the easier 3rd party porting solutions (MoltenVK).

[WolframaticAlpha]

27 minutes ago, Obioban said:

I'm not saying they shouldn't, because it would certainly be more performant if Apple did it, but that is currently one of the easier 3rd party porting solutions (MoltenVK).

MoltenVK isn't an alternative to Vulkan. It is targeted for compatibilty and as a result, vulkan code doesn't sometimes work, doesn't use many of the features of metal and often has performance issues. I am not dismissing MoltenVK. It is a viable means to deploy most vulkan code on the mac. I just mean, by putting up multiple fat abstractions between vulkan and metal, much of the advantage of vulkan is gone, and you end up with a version of OpenGL that is just somewhat better designed. The result is a bit suboptimal.

[Obioban]

4 minutes ago, WolframaticAlpha said:

MoltenVK isn't an alternative to Vulkan. It is targeted for compatibilty and as a result, vulkan code doesn't sometimes work, doesn't use many of the features of metal and often has performance issues. I mean, by putting up multiple fat abstractions between vulkan and metal, much of the advantage of vulkan is gone, and you end up with a version of OpenGL that is just somewhat better designed.

 

And my point still pertains, Doom Eternal doesn't work through Molten.VK.

I do think they should do it. I'm just saying that if I were making a list of priorities to get gaming on the mac up to speed, it would not be near top of the list.

[WolframaticAlpha]

55 minutes ago, Obioban said:

I do think they should do it. I'm just saying that if I were making a list of priorities to get gaming on the mac up to speed, it would not be near top of the list.

I think it should be near the top of the list

 

Vulkan allows for cutting off a whole translation layer and allows developers to simply make programs target Vulkan, which is standardized, unlike metal which runs on what, 10% of PC hardware and has few and far developers working in gamedev.

 

Also it would be a massive push for developers to make more games for Mac, since then you can serve nearly 1/6th of the PC users(Mac+Linux), including a relatively higher income market(Mac) and a growing one(Linux on the steam deck). It might be the push that makes many developers target Vulkan instead of DX for PC titles. Also more resources will be contributed directly to making DXVK and the like better. Since valve has explicitly thrown their weight behind Vulkan, we might actually see them support osx again.

[hishnash]

5 hours ago, WolframaticAlpha said:

Apple should just put Vulkan on the Mac. It is quite funny that the only way to run Doom eternal on the Mac is by running the Switch version through an emulator.

PC Vk titles (and tooling like DXVK) would not run on an Apple GPU using a VK driver without large changes.

VK is not like openGL, the entier point is that devs need to target the HW.  

On PC the GPUs devs target are all imminent rendering pipeline GPUs this defines the set of VK apis they can use to build the pipeline but also strongly encourages them to follow a group patterns to get optimise perfomance. 

Apples GPUs are Tile based deferred rendering GPUs, there is good VK support of these GPUs, but PC titles that are not aiming to support Mobile VK deployment do not support this subset of the VK api, and the ordering of draw calls/passes that PC title are encouraged to use for optimal perf on PC is actively sub-optimal on these GPUs.

In the end if apple were to provide a VK driver devs would still use a compile time shim (very smiler to MoltenVK in function and overhead) to allow them to run the games/tools un-modifed. 
 

2 hours ago, WolframaticAlpha said:

It might be the push that makes many developers target Vulkan instead of DX for PC titles. Also more resources will be contributed directly to making DXVK and the like better. Since valve has explicitly thrown their weight behind Vulkan, we might actually see them support osx again.

Not realy, due to the differences in AMD to Apple GPU arc.   Only a small faction of the optimisation work that Valve doe for DXVK would be relevant and much of it would even be detrimental (optimising more for AMD GPUs might well make things run worse on Apples GPUs due to the inverted pipeline). Same is true for game devs thinking of a native port. 

It is easier for devs to take the DX engine with apples tools that they already have (and must have if they want to sell on xbox and or have the studio purchased by MS).  

Why would you go build 2 VK engines one for linux and one for macOS in addition to your PS and Xbox engines? Much simpler to just let gamers on SteamDec use DXVK and then use apples HLSL tooling to make it much easer to build native macOS metal port. Some of the tools apple have shipped as part of this toolkit (not the emulation layer) make it easier to build Mac ports than it is to build linux ports (metal is much less constrained than VK, you can bring over your higher level DX11 engine concepts with the driver managing memory for you and then gradually adopted untracked memory for areas were the perf needs it).  

VK is a nightmare to develop for unless you have managed to harvest a few ex-driver developers from the GPU vendors, unlike DX there is no active support from MS as well so you cant call someone up and ask what is the best way to do something. 

[WolframaticAlpha]

1 hour ago, hishnash said:

VK is a nightmare to develop for unless you have managed to harvest a few ex-driver developers from the GPU vendors

Big disagree. Though I primarily used OpenGL more than I did Vulkan. From my experience, I preferred Vulkan to DX12, and I am far from a ex-driver developer.

 

Yes, it has a steep learning curve, but so does DX12. And the Vulkan community is a lot more active than DX12, so learning how to use it is less time consuming. And once you get past the learning curve, it is a very very well designed graphics API(imo)

 

And I mean it is a given that ll access graphics APIs are going to be much more difficult to learn than something like, say d3d11, but saying you need to be a ex driver developer sounds hyperbolic.

1 hour ago, hishnash said:

Apples GPUs are Tile based deferred rendering GPUs

Yesh, reading up on TBDR just throws up how different writing vk code for an IM GPU vs DR GPU is. Should've considered that.

 

(I plead ignorance as my excuse because I haven't reallyprogrammed for DR gpus)

[hishnash]

1 hour ago, WolframaticAlpha said:

Yes, it has a steep learning curve, but so does DX12. And the Vulkan community is a lot more active than DX12, so learning how to use it is less time consuming

yes there is a big cleaning curve on both but if your a large studio for DX12 you have access to a LOT of help from MS.   This is not about what individual devs prefure on side projects. 
 

1 hour ago, WolframaticAlpha said:

but saying you need to be a ex driver developer sounds hyperbolic.

Depends on what you are aiming to do, if you want to build a full stack engine and not re-write it 5 times while developing it you do need someone with expirance writing much lower abstractions than your existing team will be familiar with.  This is also why studios were slow to adopt DX12 or only adopting it as an additional engine backend. There is a big risk when you go into a project and non of your devs have expirance with the tooling or even lower level concepts needed, sure you don't need a ex-driver dev, someone who has worked on console engines will also be of use but within some expertise to guid you VK (or DX) is not a good choice for a AAA title game to invest in exicusivly they risk the stack of cards falling way beneath them when the dev realise they need to do a major refactor. 

The risk of using DX11 and then building an addition DX12 engine (with MS support) is much much lower than throwing that all away and saying we will build it all in VK unless you have a domain expert to guide the team. 

 

1 hour ago, WolframaticAlpha said:

Yesh, reading up on TBDR just throws up how different writing vk code for an IM GPU vs DR GPU is. 

yer making effective use of a TBDR gpu is very different to what most PC game devs are used to. Its not a matter of calling a different set of apis (well there is that) as many people might think the real complexity happens not in code but on your white board were you tend to need to completely re-think how you do some effects, how to order your render passes and draw calls. If you get it write there are some massive performance gains to be had but if you get it wrong (or don't consider it at all) there are some really big penalties. 

 

[WolframaticAlpha]

6 hours ago, hishnash said:

large studio for DX12 you have access to a LOT of help from MS.

From what I gather after talking to some friends who work in this space, DX12 is more popular moreso because of the fact that more people are using it and because of market inertia, though it might be different in other places.

[hishnash]

24 minutes ago, WolframaticAlpha said:

From what I gather after talking to some friends who work in this space, DX12 is more popular moreso because of the fact that more people are using it and because of market inertia, though it might be different in other places.

For sure, the MS support tends to be if you working on an Xbox title of course but that more or less translates to PC as well.