Sounds like Apple would be best serverd there with Checkerboard reconstruction. Is that something supported by Apple currently?
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.
Apple GPUs speculation: TBDR, RT and the benefit of wide ALUs
- Thread starter leman
- Start date
- Sort by reaction score
I doubt it would be a good fit for Apple GPUs. Checkerboard rendering usually requires fairly small tiles and those would have terrible utilization of GPU shading resources.
Apple has other ways of balancing performance and resolution, such as variable rate rasterization. As to whether they will add something like DLSS... hard to tell. Nvidia has the unique advantage here since they have a lot of training data, Apple would need to build the infrastructure for this first. But then again, wasn't AMD working on an open-source variant of DLSS?
Yes, FidelityFX SR I believe they are calling it now. They have a halod over with Content Adaptive Sharpening, but that still leaves things looking fuzzy. Compared to CB reconstruction how much faster is variable rate rasterization? And how is the resultant image quality?
Variable rate rasterization simply allows you to split a render target into zones with different resolutions, so you can rasterize an image with high resolution where you need more detail while lowering the resolution where it's less important, closer to the display edge for example.
Ah, so it isn't useful for say rendering a scene at less than 4.5k and then upscaling it to native resolution, but still retain the sharpness of the native resolution. I would ask about the performance implications versus variable rate shading, but it looks like you asked that exact question on B3D.
I mean to be fair checkerboard reconstruction/rendering really isn't a thing in PC space, nor is dynamic resolution scaling for that matter. The implementation the AC series uses on PC isn't anything like the console counterpart.
I think the takeaway message is that while upscaling is definitely useful, there is a rather wide set of prioritization and compromises to take into consideration.
DLSS came about because Nvidia wanted to adress the AI market. The tensor cores were just dead weight for gaming though, and Nvidia came up with DLSS to make a case for their presence. In terms of hardware cost it comes for free as long as Nvidia is going to have the tensor cores there anyway. In the absense of Nvidias AI ambitions however it is doubtful if DLSS would have seen the light of day. And it is NOT a "single line of code" to implement. At Nvidias recent event Crytek made a presentation (slides are floating around on the web) of their efforts to make DLSS perform well. It wasn’t trivial, and those guys are very competent and had Nvidia support.
Apple has their own set of hardware features, ambitions and limitations.
Good upscaling approaches on their platform will leverage AS features and strengths to do a good job at the task. It may make sense to utilize the NPU, but they might for instance want to avoid approaches that use higher res assets due to limited secondary storage space on their devices, or promote a solution that is really simple to implement for less experienced and/or well funded developers. They want it to be cheap in terms of power and additional gates, because a lot of their customers don’t use the phone for demanding 3D-gaming anyway, so resources spent there that are dedicated to rendering alone are largely a waste.
At the end of the day, I just don’t think the specific approach matters a whole lot. When Digital Foundry makes comparisons of DLSS quality they tend to compare with TAA which is a lot more simple (and cheap), and they still have to use stills blown up 200% to clearly demonstrate differences. Which doesn’t mean diddly squat when you are playing a game in motion and focussing on not getting killed, using a screen where the pixels are indiscernible anyway.
Last edited:
So I did some more digging it appears there is still some rasterization happening but not for lighting. Seems like it is using a similar technique as Metro Exodus Enhanced Edition is using. With the biggest difference being ME appears to be able to run at 4k60 with RT on consoles (my 6900 struggles with Q2RT at higher resolutions)
So Apple has listed the WWDC Sessions for this year, numbering over 200 in total. This one scheduled for June 10th caught my eye:
Optimize your high-end games for Apple GPUs: We'll show you how you can use our rendering and debugging tools to eliminate performance issues and make your games great on Apple platforms. Learn from our experiences working with developers at Larian Studios and 4A Games as we help them optimize their games for Apple GPUs. We'll explore various techniques for improving your game's performance, including optimizing shaders, reducing memory bandwidth utilization, and increasing the overlap of your GPU workloads. We'll also dive into the new GPU Timeline profiling tool in Xcode 13 to identify possible performance bottlenecks in “Divinity: Original Sin 2” when running on iPad. For this session, you should be familiar with the tile-based deferred rendering architecture in Apple GPUs, and have a working knowledge of Xcode and the Metal API. Check out “Discover Metal debugging, profiling, and asset creation tools” or the WWDC20 session “Optimize Metal apps and games with GPU counters” to learn more about using our tools to profile graphics workloads.
I know Apple has gotten a lot of flak over perceived tepid support for games on the Mac, but they clearly still have it in mind. It's no surprise that they specifically mention Larian and 4A as studios that they have worked with and I would note that the first sentence specifies "high-end games". It seems to me that Apple is willing to work with developers who want to work with them, and are going to provide assistance for those who are interested.
There are also multiple sessions having to do with ray tracing, they aren't specifically just for gaming, but at least one session does appear to highlight it.
Anyway, it'll be interesting to see exactly how this shakes out, and what impact it will have, if any.
Optimize high-end games for Apple GPUs
Optimize your high-end games for Apple GPUs: We'll show you how you can use our rendering and debugging tools to eliminate performance issues and make your games great on Apple platforms. Learn from our experiences working with developers at Larian Studios and 4A Games as we help them optimize their games for Apple GPUs. We'll explore various techniques for improving your game's performance, including optimizing shaders, reducing memory bandwidth utilization, and increasing the overlap of your GPU workloads. We'll also dive into the new GPU Timeline profiling tool in Xcode 13 to identify possible performance bottlenecks in “Divinity: Original Sin 2” when running on iPad. For this session, you should be familiar with the tile-based deferred rendering architecture in Apple GPUs, and have a working knowledge of Xcode and the Metal API. Check out “Discover Metal debugging, profiling, and asset creation tools” or the WWDC20 session “Optimize Metal apps and games with GPU counters” to learn more about using our tools to profile graphics workloads.
I know Apple has gotten a lot of flak over perceived tepid support for games on the Mac, but they clearly still have it in mind. It's no surprise that they specifically mention Larian and 4A as studios that they have worked with and I would note that the first sentence specifies "high-end games". It seems to me that Apple is willing to work with developers who want to work with them, and are going to provide assistance for those who are interested.
There are also multiple sessions having to do with ray tracing, they aren't specifically just for gaming, but at least one session does appear to highlight it.
Anyway, it'll be interesting to see exactly how this shakes out, and what impact it will have, if any.
I skimmed the documentation, most Metal changes so far seem to do with better debugging support (super important for a good dev experience) as well as raytracing. Pretty sure this means we are getting hardware RT (or at least faster RT) later this year. Half of sessions are RT related and there is one on hybrid rendering (as already pointed out by @Colstan).
Great catch Colstan! That is for me the most interesting news at this WWDC. That and the other sessions leman wrote about make me think if there is a connection.
4A has ported all Metro games to Mac. The reason they couldn't bring Exodus Enhanced Edition to Mac was obviously the lack of hardware ray tracing on Macs since that is what the Enhanced version is all about mainly. 4A has also big plans for Metro Exodus in the future with a new Metro game, multiplayer and a new AAA experience alongside the Metro series.
Since Apple wants to showcase the collaboration with 4A I think Mac is included in 4A's future plans and one of them is to bring ray tracing to Mac when the hardware allows it.
Another curious thing is that the session is called "Optimize your high-end games for Apple GPUs" and it's described as "Learn from our experiences working with developers at Larian Studios and 4A Games as we help them optimize their games for Apple GPUs". Even though Metro Exodus works on M1 it seems that it was built and optimized for Intel/AMD Macs with Molten VK running via Rosetta so I wonder in what way it was optimized for "Apple GPUs". Does it mean there will be a Apple Silicon native port soon? Perhaps with ray tracing with new and more powerful Apple SoCs? I noticed Apple says "as we help them optimize their games", not helped, meaning it's an ongoing project. Very exciting indeed!
Last edited:
I like your optimismGreat catch Colstan! That is for me the most interesting news at this WWDC. That and the other sessions leman wrote about make me think if there is a connection.
4A has ported all Metro games to Mac. The reason they couldn't bring Exodus Enhanced Edition to Mac was obviously the lack of hardware ray tracing on Macs since that is what the Enhanced version is all about mainly. 4A has also big plans for Metro Exodus in the future with a new Metro game, multiplayer and a new AAA experience alongside the Metro series.
Since Apple wants to showcase the collaboration with 4A I think Mac is included in 4A's future plans and one of them is to bring ray tracing to Mac when the hardware allows it.
Another curious thing is that the session is called "Optimize your high-end games for Apple GPUs" and it's described as "Learn from our experiences working with developers at Larian Studios and 4A Games as we help them optimize their games for Apple GPUs". Even though Metro Exodus works on M1 it seems that it was built and optimized for Intel/AMD Macs with Molten VK running via Rosetta so I wonder in what way it was optimized for "Apple GPUs". Does it mean there will be a Apple Silicon native port soon? Perhaps with ray tracing with new and more powerful Apple SoCs? Very exciting indeed!
With Aspyr out of the picture 4A is the new Aspyr!
I noticed Apple says "as we help them optimize their games", not helped, meaning it's an ongoing project.
Last edited:
We'll see after the session gets presented, but I think you folks are reading what you want to see into this rather than what is actually there.
Unclear how much Apple has only put the RT Metal updates into the Apple GPU branch. If they are still expanding RT coverage on Intel and AMD GPUs then this session doesn't really imply that. Usually that is something covered in the "State of the Union" address. I may have missed it during the extended "XCode Cloud" infomerical the SoU partially turned into this year.
Apple skewed the talk toward Apple GPU in what they talked about, but wasn't clear just how lopsided they are taking it.
From Molten VK docs:
"...You can use the standard Vulkan vkCreateShaderModule() function to provide your own MSL shader code. To do so, set the value of the magic number element of the SPIR-V stream to one of the values in the MVKMSLMagicNumber enumeration found in the mvkDataTypes.h header file. ..."
Metal Shaders with Molten is works. In fact, that's what Molten has to do with the Vulkan shader intermediate code ( SPIR-V) .... turn it into Metal Shader. Apple makes it all have to shift over to Metal at the lower levels. If want access to GPU compute cores ... it Metal. So if going for maximum optimization, the developer has to hand convert the shaders into Metal.
Probably not. Probably some combo of Molten updates to cover some of newer the Metal updates and further native on the compute kernels. So depends upon point of view. RT with some drawing or drawing with some RT.
If game company has branches in their code to skip SPIR-V and go native to CUDA on Nvidia cards , then adding another branch to cover Metal probably isn't a big deal.
Over time they could iterate to Metal native for the whole game engine port, but for now probalby haven't done a "big bang" replacement.
Unclear how much Apple has only put the RT Metal updates into the Apple GPU branch. If they are still expanding RT coverage on Intel and AMD GPUs then this session doesn't really imply that. Usually that is something covered in the "State of the Union" address. I may have missed it during the extended "XCode Cloud" infomerical the SoU partially turned into this year.
Apple skewed the talk toward Apple GPU in what they talked about, but wasn't clear just how lopsided they are taking it.
From Molten VK docs:
"...You can use the standard Vulkan vkCreateShaderModule() function to provide your own MSL shader code. To do so, set the value of the magic number element of the SPIR-V stream to one of the values in the MVKMSLMagicNumber enumeration found in the mvkDataTypes.h header file. ..."
Metal Shaders with Molten is works. In fact, that's what Molten has to do with the Vulkan shader intermediate code ( SPIR-V) .... turn it into Metal Shader. Apple makes it all have to shift over to Metal at the lower levels. If want access to GPU compute cores ... it Metal. So if going for maximum optimization, the developer has to hand convert the shaders into Metal.
Apple Silicon native port soon? Perhaps with ray tracing with new and more powerful Apple SoCs? Very exciting indeed!
Probably not. Probably some combo of Molten updates to cover some of newer the Metal updates and further native on the compute kernels. So depends upon point of view. RT with some drawing or drawing with some RT.
If game company has branches in their code to skip SPIR-V and go native to CUDA on Nvidia cards , then adding another branch to cover Metal probably isn't a big deal.
Over time they could iterate to Metal native for the whole game engine port, but for now probalby haven't done a "big bang" replacement.
Don't be a party pooper! Just kidding.
Still exciting that they collaborate. I think 4A will keep supporting Mac. I reacted to Apple's statement "we help them optimize their games for Apple GPUs". They don't say they help them to optimize their games for Metal. That's the reason I got the impression that it's not just about optimizing Molten VK for Metal but optimizing the game for Apple GPUs in some special ways (like native support), but maybe I'm reading too much into it.
I was also thinking of AMD SoCs in PS5 and Xbox X which can handle ray tracing and Metro Exodus Enhanced. So it should be possible for future Apple SoCs.
Last edited:
This is not related to TBDR per se, but Metal on the Mac will support variable refresh-rate displays for games.
This require changes in the presentation code, unless I'm mistaken.
Why can they make this automatic? I believe developers don't need to change anything to enable FreeSync or G-Sync on Windows.
This require changes in the presentation code, unless I'm mistaken.
Why can they make this automatic? I believe developers don't need to change anything to enable FreeSync or G-Sync on Windows.
A glimpse of Divinity and Metro Exodus at 45 min: https://developer.apple.com/videos/play/wwdc2021/102/
Monterey adds support for adaptive sync displays.
Monterey adds support for adaptive sync displays.
VRR support, but has to be at the app level versus the system just tracking the frame rate and adjusting refresh rate to match. I am curious how many will add support. Does anyone know, when they say they support PS5 DualSense haptics, are they talking about the precise rumble only, or does it also support the tension on the triggers as well?
I'm pretty sure Apple could enable a lot of rendering/display options system wide, like the V-Sync mode, anti-aliasing and anisotropic filtering, overriding games settings, like it is possible on Windows via GPU vendor utilities. But these are typically not the kind of settings Apple wants users to see.
So they leave that to developers.
Of note, there was a time, before the intel transition, when ATi (now AMD) was proposing some "ATi utility" on OS X, which allowed users to tweak rendering settings, like enabling AA for a game that did not do it natively.
So they leave that to developers.
Of note, there was a time, before the intel transition, when ATi (now AMD) was proposing some "ATi utility" on OS X, which allowed users to tweak rendering settings, like enabling AA for a game that did not do it natively.
I haven't watched the relevant session yet, but I imagine they want the developer to have full control of presentation so that they have the chance to adjust their animation/simulation accordingly. If I understand it correctly, the usual FreeSync/G-Sync simply matches the display refresh rate to the GPU rendering rate. Apple instead gives you low-level control over these things. I can imagine that having detailed information (and control) over the timings could allow one to produce smooth animations beyond what's possible with the traditional "draw as quickly as possible" approach.
I guess if a developer is explicitly targeting the Mx/Ax GPU and not others, then this would be a useful feature though I would argue maybe they should spend the time finding the frame drops and getting rid of them instead of spending time making the refresh rate adapt to hide it. System level VRR would be okay when the dev is targeting a larger swath of GPU hardware and cannot code for specific GPU.
Platforms State of Union from about 45 mins to 50 mins.
Platforms State of the Union - WWDC21 - Videos - Apple Developer
Take a deeper dive into the new tools, technologies, and advances across Apple platforms that will help you create even better apps.
(odd there is no transcript tab there. )
Says that the major focus is better graphics across all of Apple's powerful devices. ( the high end MPX modules certainly fit that ).
There is two parts to variable refresh. One is to Apple's ProMotion displays. That is mainly to the iPad Pro (and perhaps next Pro iPhones ). That one is probably Apple GPU specific. They mention match input to render time. For ProMotion Apple turns it off and on depending upon what user is doing because there is a "power saving" aspect here too. They don't want it on all the time because that will drain the battery faster. That doesn't necessarily exclude the AMD GPUs , but kind of fuzzy. ( Metal Presentation time timeline control could be portable. )
The second is to Adaptive Sync standard support (VESA standard ) doesn't seem to be Apple GPU specific. So should show up on both the supported AMD GPUs on x86 and on Apple GPU. Since exposing a VESA standard, there should be some super proprietary wrapper around that.
The Platform State of Union was a bit more "glossy" this year. i'm not sure this has show up in a more detailed session yet.( went through the Metal ones from Tuesday and don't remember them there and search through transcripts doesn't so a hit either. ) But there could be some big synchronization/data management details mismatch there. But from the generic perspective of call out to a "ray trace function" to help with lighting.. not that much different than calling out to raster approximating engine. A different computation happens on the call but making a call is an API to the result.
As for the Vulkan port game engines. Not clear after Apple's hybrid render session that does or doesn't map cleaning into Vuklan/SPIR-V semantics or not. ( I haven't looked deeo at what Vulkan is doing on coupling to their open RT framework, but doesn't seem to be major semantic gaps to block decently good performance. )
P.S. some mention of "Portability for different Ray Trace Engines" was mentioned in Metal Ray tracing session.
Enhance your app with Metal ray tracing - WWDC21 - Videos - Apple Developer
Achieve photorealistic 3D scenes in your apps and games through ray tracing, a core part of the Metal graphics framework and Shading...
[ that is really "map down into Metal" portability. ]. So some hope not being hostile to other engines like Vulkan/SPIR/RT being mapped down into Metal.
one last P.P.S.
the hybrid session Apple GPU gets some uplift in the switching back and forth between raster step and ray tracing because the tile memory can hold the data structure so don't have to do a complete write back to base RAM. AMD's Infinity cache should blunt that a bit if generated code is properly optimized. There is a path to do that which is GPU neutral above the API interaction line. But is Apple going to tilt the Metal playing field to Apple GPU over time?
Last edited:
Another curious thing is that the session is called "Optimize your high-end games for Apple GPUs" and it's described as "Learn from our experiences working with developers at Larian Studios and 4A Games as we help them optimize their games for Apple GPUs". Even though Metro Exodus works on M1 it seems that it was built and optimized for Intel/AMD Macs with Molten VK running via Rosetta so I wonder in what way it was optimized for "Apple GPUs". Does it mean there will be a Apple Silicon native port soon? Perhaps with ray tracing with new and more powerful Apple SoCs? I noticed Apple says "as we help them optimize their games", not helped, meaning it's an ongoing project. Very exciting indeed!
Had a chance to quickly scan the transcript. Several points that mention that 4A's use of a transloation layer was a optimization point after collecting debug and trace information in the Metal's user development tools. ( those have also gotten better with they new iOS and macOS updates coming with new the bleeding edge XCode. ). It doesn't mention dumping the translation tools all together. They changed some default flags the translation layer was using to compile Metal. ( threw away accuracy; "fast math" that skips over error checikng and overflow tests) and speed when up.
It is a good sign that pragmatically Apple is helping the Molten VK layer get knowledge updates to make Vulkan games go faster. ( Presuming that 4A (or Apple) passed this info along to the open source group handling Molten VK). That will cut porting costs and enable more engines to make the transition and stay profitable.
Long, long term 4A may or may not port their engine to Metal. Egnine develpers do have to know how Metal works so that they can fully decode what the Metal trace and debug tools is telling them. They can't 100% hide in Vulkan and GLSL/HLSL and SPIR-V debugging tools . There shoulld at least be some folks on the "Port" team chain that have some experience writing some Metal shader language code and using the tools to opitmize it. But the whole engine team doesn't necessarily need to jump over to becoming experts.
If the folks doing Molten VK get deeper knowledge and do better translation and update guidance documentation some stuff will get "for free".
Bigger picture, Apple driving the developer's choice of where to dedicate GPU optimization time to on macOS M1 ports. There is only one answer, so there is only one selection. That keeps developers focused on putting in the Apple GPU specific updates to legacy Mac app code. Another year skewing the playing field their way should be enough to open up a dominate foothold on how much time their option gets in future allocations even if open up an option (or two dGPU Intel ).
I suspect that Apple's planned higher end GPU core count options are even more sensitive to lack of bandwidth compression hook usage than the M1's GPU. So Apple is highly motivated to drive those optimizations to the code sooner rather than gradually over an extended time. Unles they let go of the homogeneous memory approach, the scaling will out race the compression 'tricks' at some point.
Last edited:
Yes, I saw that. A bit disappointing that they've used the "translation layer" instead of a native port.
More people need to buy the game to prove it is worth the man hours (both cost and time) for them to make 4A Engine macOS native.