Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Vulkan Apps Now Compatible With macOS and iOS
- Thread starter MacRumors
- Start date
- Sort by reaction score
Realistically, since so many games now are made in an engine such as Unity or Unreal, porting games has already been mostly trivial a lot of the time. It's not as common these days to have to actually port a game from scratch where you worry about the details of Vulkan, Metal, etc. Now you have to worry about developers signing up to be published by Microsoft, who then prohibits the game from appearing on non-Microsoft platforms even though there are no technical issues preventing it.
--Eric
Not in my tests. Metal still at least 15 frames slower than Windows in the games I tried however it's significantly faster than OpenGL.
When they get to < 10 fps difference, then we can start considering removing our bootcamp partitions for gaming.
When they get to < 10 fps difference, then we can start considering removing our bootcamp partitions for gaming.
Like @groove-agent says, that doesn't match my testing either. I just compared that particular game (F1 2016, graphics maxed out, vsync set to ”auto”) to how it runs in Windows 10 and MacOS 10.13.3 on my Mac Pro (Mid 2010) with GTX 970 graphics at 1900 x 1200 pixels (results attached). For whatever reason – be it related to the required Nvidia Web Driver etc. – the Mac version goes down 17 frames per second lower than the Windows version. That's quite a big performance difference on the same hardware, and it's not favoring MacOS in this case, even with Metal. Maybe things are different (more even?) with AMD graphics?
Edit:
Seeing the benchmark result in the video linked to above is average 55 fps and minimum 39 while I got average 50 fps and minimum 32 fps it does seem the drivers for AMD graphics are better in this case as the GTX 970 I have is supposed to be a little bit more powerful than the RX 480 used in the video above. Hmm… But I guess that's still hard to tell since I'm running a totally different computer (older CPU, but more cores) than the MacBook Pro in the video.
No, probably not in the near future at least. I mean in Windows you even have the GPU vendors (AMD and NVIDIA) optimize their drivers for specific games (major new releases at least).
Agreed. If the difference is less than 10 fps then we might start talking. But almost 20 fps difference on the minimum frames per second? Not good enough.
To be fair that's also version 1 of Metal.
Not that I know if there would have been any benefits if it moved to Metal 2. I think F1 2017 uses Metal 2, at least Dirt Rally does. But in my benchmarking with that game (Dirt Rally) on the same hardware I mentioned in the beginning of this post, Windows was still a lot better when it came to the minimum fps.I guess and hope Metal –and the developers using it – will be able to improve performance down the road. And also maybe AMD and NVIDIA will have even more reasons to develop separate MacOS drivers once external GPUs become more common for Macs. Will be interesting to see how things are in a year or two.
Attachments
Last edited:
I don’t believe that MoltenVK will be immediately useful to most serious Mac games developers. Aspyr, Feral, Unity and here at Epic we already have direct, native Metal backends that are (or at least should be) faster and support a greater range of features than another intermediate translation library.
Specifically MoltenVK has a list of limitations that make it sufficient for porting mobile Vulkan games and games with a primarily D3D9-era rendering engine, but probably inadequate for most modern D3D11+ game engines.
Principally anything that requires geometry shaders or tessellation shaders is currently not going to work as MoltenVK doesn’t support them. They are *optional* features in Vulkan so it can still call itself conformant by contrast for D3D these are *required* features in D3D11 onward so games do use them, sometimes extensively. Moreover the approach MoltenVK takes to recompiling shaders makes it infeasible to impossible for them to be supported without significant work and performance penalties. Metal doesn’t have direct equivalents so the MoltenVK library would need to defer SPIRV to Metal translation until said shaders are used together in a Shader Pipeline at runtime. Only then could it recompile them to Metal and emulate all the necessary behaviour but this would result in a big performance hit on the CPU. It would also be harder to adopt the native features offered by Mac Metal to deal with these cases and hurt GPU performance.
The other gotcha will be emulating type conversion of data between the resources and the shader. Metal doesn’t have a performant way to do that in all cases right now, so you need to use multiple different techniques to achieve the result while minimising the performance penalty. MoltenVK appears to support only a trivial subset of D3D’s implicit resource type casts which wouldn’t be enough for UE4.
I wish them well in their efforts but this is not going to magically result in better performance in games shipped by Feral, or Epic, etc. It might well end up making it easier for smalller studios with their own engines, esp. mobile focused developers, and that is no bad thing.
Specifically MoltenVK has a list of limitations that make it sufficient for porting mobile Vulkan games and games with a primarily D3D9-era rendering engine, but probably inadequate for most modern D3D11+ game engines.
Principally anything that requires geometry shaders or tessellation shaders is currently not going to work as MoltenVK doesn’t support them. They are *optional* features in Vulkan so it can still call itself conformant by contrast for D3D these are *required* features in D3D11 onward so games do use them, sometimes extensively. Moreover the approach MoltenVK takes to recompiling shaders makes it infeasible to impossible for them to be supported without significant work and performance penalties. Metal doesn’t have direct equivalents so the MoltenVK library would need to defer SPIRV to Metal translation until said shaders are used together in a Shader Pipeline at runtime. Only then could it recompile them to Metal and emulate all the necessary behaviour but this would result in a big performance hit on the CPU. It would also be harder to adopt the native features offered by Mac Metal to deal with these cases and hurt GPU performance.
The other gotcha will be emulating type conversion of data between the resources and the shader. Metal doesn’t have a performant way to do that in all cases right now, so you need to use multiple different techniques to achieve the result while minimising the performance penalty. MoltenVK appears to support only a trivial subset of D3D’s implicit resource type casts which wouldn’t be enough for UE4.
I wish them well in their efforts but this is not going to magically result in better performance in games shipped by Feral, or Epic, etc. It might well end up making it easier for smalller studios with their own engines, esp. mobile focused developers, and that is no bad thing.
Maybe I'm wrong here, but my understanding is that you do not have to translate the SPIRV shaders to MSL at runtime. MoltenVK apparently comes with a separate conversion tool that's supposed to allow you to do this beforehand, and then you can pass your converted MSL shaders directly to your Vulkan code.
It's surely an extra step during the porting process, but you wouldn't have to deal with the performance hit.
Last edited:
@marksatt
Good to hear some input from someone with good insight.
Quite a bit off-topic, but do you know what's going on with the major pauses/lag in between seemingly good frame rates in the MacOS version of Fortnite?
https://www.dropbox.com/s/nzt0h1s9hvrzgad/Fortnite_major_hiccups.m4v?dl=0
Or is the problem I see perhaps related to the NVIDIA Web Driver which is required for the GTX 970 I have to work in MacOS? Sorry, maybe I should report this somewhere else…
Good to hear some input from someone with good insight.
Quite a bit off-topic, but do you know what's going on with the major pauses/lag in between seemingly good frame rates in the MacOS version of Fortnite?
https://www.dropbox.com/s/nzt0h1s9hvrzgad/Fortnite_major_hiccups.m4v?dl=0
Or is the problem I see perhaps related to the NVIDIA Web Driver which is required for the GTX 970 I have to work in MacOS? Sorry, maybe I should report this somewhere else…
That’s what I said sir, by doing this offline for SPIRV you avoid the runtime performance hit BUT you CANNOT use some/all Metal specific feature and you CANNOT emulate geometry or tessellation shaders. Emulating them requires the full set of shaders in a pipeline so that you can rewrite them to use Metal’s similar but not equivalent features. That is known only at runtime in most engines - not all though. That means combining vertex + (hull and/or geometry) shader stages into compute shaders that must run in an earlier compute command buffer, separate to the later draw call that uses the (domain + pixel shader). Plus all the associated buffer allocations and resource binding shenanigans- it’s actually bloody hard work to get right!
[doublepost=1519686438][/doublepost]
@marksatt
Good to hear some input from someone with good insight.
Quite a bit off-topic, but do you know what's going on with the major pauses/lag in between seemingly good frame rates in the MacOS version of Fortnite?
https://www.dropbox.com/s/nzt0h1s9hvrzgad/Fortnite_major_hiccups.m4v?dl=0
Or is the problem I see perhaps related to the NVIDIA Web Driver which is required for the GTX 970 I have to work in MacOS? Sorry, maybe I should report this somewhere else…
Looks like it is either texture streaming or shader compilation or a combination of the two. I’ve explained the challenges of dealing with the initial shader setup at runtime, even with precompiled shaders, elsewhere. It still isn’t a solved problem in UE4 or Fortnite and it likely never will be perfect. This isn’t the forum to report problems - that should be done over at the Fortnite forums and the feedback mechanism.
Why, ‘twas a reasonable misunderstanding. The devil is always in the details for graphics tech and amazing headlines are rarely all they are cracked up to be. In this case the tech takes a naive approach which is faster for iOS but really limits usefulness on macOS.
I am fairly sure that Feral take something like the approach I suggested for games like Deus Ex Mankind Divided and Rise of the Tomb Raider, although they will also have lots of tech to precompile and/or amortise the cost.
Were Apple to ever expose the geometry and hull stages they’d make our lives and things like MoltenVK a lot easier for PC->Mac. Mac->iOS would get harder though.
Oh thank god. Why Apple hasn't taken 3D graphics acceleration seriously till the last couple of years blows my mind. But there is ALOT of catch up to do.
Mobile GPUs are architecturally *very* different from desktop GPUs so don't have the same features. Metal's API design was predominantly driven by the needs & capabilities of iOS GPUs, hence why geometry shaders are absent and why the tessellation pipeline is completely different to D3D.
Obviously the macOS hardware could support these features in a way that is directly equivalent to D3D and were Apple to do that and developers elected to use said features then those titles would need more work to run on iOS. That being said, it already takes *substantial* effort to rework a macOS title to fit on iOS, as shown by Aspyr's heroic efforts with Civ VI and Feral's equally impressive Rome & GRID ports. Given the difference in performance profile of iOS vs. macOS devices it probably wouldn't really matter as any game that used these features would likely not be viable anyway.
Yes it seems all Fortnite users have this issue, I get even 2-3 seconds lag with 60fps
Well the caveat is that it's not fully functional (e.g. no tessellation), at least for now.
Is Vulkan 1.1 better?
https://arstechnica.com/gadgets/201...compatibility-as-khronos-looks-to-the-future/
https://arstechnica.com/gadgets/201...compatibility-as-khronos-looks-to-the-future/