To be fair, they did make the wild lands benchmark after basically abandoning iOS for a few years. So anything is possible I guess.You can download the free source code of one of WWDC RT demos and compile it in Xcode for example
I wouldn't expect UL to go through the trouble of porting these benchmarks to Apple Silicon, because... why would they? Nobody really cares exceptnerdstechnology enthusiasts like us. Once (and if) there is a sizable gaming market for Macs, then we will see these benchmarks popping up, but even than it's questionable (as there is no competing hardware).
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
Posting here for a more technical discussion.
What do you make of the fact that GFXBench is just as fast under Rosetta 2?
https://www.anandtech.com/show/16252/ma ... 1-tested/3
Does it mean that the universal version of the app uses the same Metal code for both Apple GPUs and non-Apple GPUs? Which would imply that the developer did not use the Metal features that maximise the performance of Apple GPUs, even on iOS. Because if the iOS version is optimised for TBDR GPUs, why have the developers not used this iOS Metal code in the universal macOS version? Surely, this universal version should have run better than the X86 version under Rosetta.
What do you make of the fact that GFXBench is just as fast under Rosetta 2?
https://www.anandtech.com/show/16252/ma ... 1-tested/3
Does it mean that the universal version of the app uses the same Metal code for both Apple GPUs and non-Apple GPUs? Which would imply that the developer did not use the Metal features that maximise the performance of Apple GPUs, even on iOS. Because if the iOS version is optimised for TBDR GPUs, why have the developers not used this iOS Metal code in the universal macOS version? Surely, this universal version should have run better than the X86 version under Rosetta.
If the performance is the same between the native and the Rosetta-transpiled versions, my conclusions would be that a) it is not CPU limited and b) it uses the same rendering algorithms for both versions (as you say)
Anyway, do we even know that the iOS version is specifically optimized for TBDR? It's much simpler to ship Metal rendering loop that works on all hardware than to write a specifically optimized version for Apple hardware.
Indeed, that's what I was wondering about. It would be interesting to run the iOS version on these Macs.
But if this test does use the same Metal code for all Apple hardware, it also means that the mobile version doesn't use half-precision numbers in shaders, as opposed to what some analysts suspected, right?
Not necessarily, iOS driver might be aggressive about reducing the calculation precision where appropriate. They could be also doing the same on macOS side, who knows. One would need to carry out some carefully designed numeric tests to check for it, but that requires expert work. Not too many people around who are experts in numerics and experts in GPU programming at the same time
GFXBenchmark actually had this really neat feature where they measure image quality (as a difference between produced and expected image), but it doesn't seem like Metal versions of the benchmarks support it.
Having looked at various benchmarks, it seems that the M1 performs as expected given its specs (TFLOPS, Gpixels/s and Gtexels/s) and sometime worse.
For instance, it's 40% faster than the intel Xe 96EU on 3DMark Wild Life, while I would have expected it to give 50% better performance given its specs.
In several of the tests performed by Anantech, the M1 performs worse than expected. In RoTR, the 1650 is 47% faster while its specs (FLOPS and such) are about 20-30% better. I wouldn't blame rosetta, since it shouldn't make a difference at this resolution.
At any rate, I don't see much evidence than TBDR makes better use of the hardware, i.e, that the M1 performs closer to its theoretical maximum performance. It performs better than expected given its specs on GFXBench, but this is a a mobile benchmark that possibly makes use of half precision numbers in shaders, favouring mobile GPUs.
We're excited that the M1 Macs beat previous Mac models, but we're comparing it to some intel Iris garbage that has less than 1/6 the pixel fill rate.
However, the M1 GPU power consumption (7W in RoTR) is very low. I suppose the TBDR design and unified memory pay off here, and that's not just due to being on 5 nm.
For instance, it's 40% faster than the intel Xe 96EU on 3DMark Wild Life, while I would have expected it to give 50% better performance given its specs.
In several of the tests performed by Anantech, the M1 performs worse than expected. In RoTR, the 1650 is 47% faster while its specs (FLOPS and such) are about 20-30% better.
I wouldn't blame rosetta, since it shouldn't make a difference at this resolution.At any rate, I don't see much evidence than TBDR makes better use of the hardware, i.e, that the M1 performs closer to its theoretical maximum performance. It performs better than expected given its specs on GFXBench, but this is a a mobile benchmark that possibly makes use of half precision numbers in shaders, favouring mobile GPUs.
We're excited that the M1 Macs beat previous Mac models, but we're comparing it to some intel Iris garbage that has less than 1/6 the pixel fill rate.
However, the M1 GPU power consumption (7W in RoTR) is very low. I suppose the TBDR design and unified memory pay off here, and that's not just due to being on 5 nm.
It’s worth keeping in mind that none of the software for macOS is written for TBDRs. Nevermind that the original code, whether targeting consoles or PCs wasn’t, no macOS systems were TBDRs either so being "native Metal" means nothing. Realistically, software migrating from iOS will take best advantage of the underlying architecture, (whereas all comparisons between platforms will be done with software developed for PC/consoles. We should be used to it by now.?)
While these calculations are interesting from a purely academic standpoint, and could conceivably reveal certain kinds of cheating, from a practical standpoint they don’t provide much. The proof of the pudding is in the eating. Unless you get distracted by artifacting, the procedure used does its job.Not necessarily, iOS driver might be aggressive about reducing the calculation precision where appropriate. They could be also doing the same on macOS side, who knows. One would need to carry out some carefully designed numeric tests to check for it, but that requires expert work. Not too many people around who are experts in numerics and experts in GPU programming at the same time
GFXBenchmark actually had this really neat feature where they measure image quality (as a difference between produced and expected image), but it doesn't seem like Metal versions of the benchmarks support it.
This is particularly true on modern devices that (apart from some PCs) typically have pixels small enough to be effectively invisible to the naked eye. For a colour or luminance error to be visible, it has to be really large (bright pixel in dark area), have persistence (a colour error showing up for 1/60:th of a second on the side of the screen won’t be noticed), and probably spread over a large number of pixels for any realistic precision related problem to be detected.
Making typical frame by frame mathematical analysis of mean errors really doesn’t map to the problem at hand.
Aiming for perfect rendering is a pointless waste of resources.
But it might always means nothing. Will there be there a single game engine coded with Metal in mind? That's the question I always ask myself when I watch these WWDC videos. "This looks awesome, but will any developer make use of it?". Porting houses are not going to redesign a game engine around Metal. They translate the DX code into Metal with automatic tools and make sure the results is good enough (if we're lucky, others will use MoltenVK or some other JIT translation). For Unity, this may be a bit different. I wouldn't count on Unreal Engine anymore. It's a lost cause, given the ongoing legal battle.
But anyway, Mark (who sounded like he was the only Metal developer in UE4 team at Epic) made clear that PC UE4 was not designed around modern APIs, and that it could not take advantage of many Metal features.And even if a 3D engine is not written with TBDR in mind, TBDR should still make a difference as hidden surface removal and such are still done by the GPU.
I really wish they'd do something about this situation. Like, even if they don't want to purchase a small studio to showcase Metal (which they should), at least partner with one or more to optimise their software for it.
This is the same old topic. Apple doesn't care about gaming. Some say that Apple is right not to bother, since no one buys a Mac for gaming. I say that Apple loses sales, as customers would have bought a Mac if at least it could run some major AAA titles. I believe that many people (students in particular) want an all-around laptop that they could use for gaming from time to time. The M1 MacBooks would be tailored for them... if only macOS had the games. At least, intel Macs could run Windows.
If Apple invested into gaming only 1/10th of what they invest into Music and TV, things would drastically change.
All this shows is that peak theoretical FLOPS is a poor measure for graphical performance. I think Nvidia has already convincingly demonstrated the same with their Ampere architecture.
At the same time, in practical gaming tests we have M1 delivering about 50-70% performance of a 1650 (Tomb Raider, Borderlands). That is not bad at all, especially considering the facts that these games run under Rosetta, are not the best ports, we are comparing macOS vs. Windows with it's gaming driver optimizations and of course that the 1650 alone consumes 3x as much power as the entire M1 (CPU + GPU + RAM) while having 2x faster RAM. Also note that M1 performance scales very well with resolution, where a traditional memory-bandwidth starved iGPU will start failing — that's one of the benefits of TBDR.
Taking advantage of Metal and taking advantage of Apple-specific features of Metal are different things. Plenty of engines out there can take good advantage of Metal (like Unity), but of course nobody targets Apple TBDR GPU on the desktop right now simply because those GPUs are so new. I suppose that Baldur's Gates 3 will have some optimizations built in. Anyway, if Apple Silicon Macs are popular, we will see devs add support — it's too lucrative of a market to pass it.
If they didn't care about gaming, why would they spend significant time and effort improving the game dev ecosystem? They have built a very impressive GPU IP that clearly targets gaming (if you only care about pro apps, why even bother with complicated stuff like TBDR), Metal features are all about gaming, they are constantly improving debugging experience for game developers and Big Sur has excellent game controller support.
I'm not just considering FLOPS, but Pixels/s and Texels/s.
For RoTR, yes there could be some game-specific driver tricks. But for Wild Life? I think the M1 should do better. It has >50% more FLOPS, Texel/s and Pixel/s than the Intel Xe G7, but performs only 40% better. It has higher specs than the 1650 ti Max-Q but achieves a lower score. It cannot be due to Rosetta or lower memory bandwidth (at least not compared to the intel Xe, with has the same memory interface and less accessible RAM).
I should have been more specific. I meant that Apple does do much for much for Mac (and AAA) gaming specifically. The Mac benefits from efforts spent into other platforms, which is the case for the M1. Apple Arcade is a joke compared to what Apple is investing into Music and TV+.
From what I've seen M1 scores 18k in wild life. Tiger Lake does 8k, 1650 Ti max Q 19k. I think these scores make sense. The 1650 has the same amount of ALUs as the M1, but slightly higher clocks.
By the way, despite comparable peak TFLOPS metrics, the 1650 variants significantly outperform M1 in synthetic Geekbench compute. This is undoubtedly the effect of higher memory bandwidth. But in practical pro workloads utilizing compute, M1 is likely to be faster as it doesn't have to perform memory copies.
Apple Arcade is a joke, BUT it IS Apple partnering with developers to provide some impetus towards developing games using Apple’s frameworks. I wouldn’t be surprised if part of what Apple gets from this is knowledge about what game developers might want for Mac gaming. A lot of the Apple Arcade games do end up on other platforms, so if Apple’s learning how to help developers use their cross-platform code to develop a more Apple-native solution, that’s a good thing.
A score of 8k for the Intel Xe 96EU would be far too low, it's even lower than the A14. I wouldn't trust these scores, and rather ruse this result for reference.
According the techpowerup and notebookchek, the 1650 ti max-Q has lower clock speed, computer power and fill rates than the M1.
The scores on the 3Dmark website are probably from the 15W version of Tiger Lake. ZenBook Flip uses a 30W Tiger Lake (with PL2 of 50 watts).
That will all depends on the clock. Both 1650 max-q and M1 have 1024 FP ALUS, so their peak FLOPS will be 2048*clock. Apple claims that M1 has 2.6TFLOPS, which will put its max clock around 1.25Ghz. The clocks for the 1650 GPUs will vary from laptop to laptop but should be around the similar ballpark from what I've seen.
I agree that the intel Xe consumes much more power than the M1 GPU. But if we want to compare theoretical performance to actual performance, we should use results from tests that are not affected by throttling.
Oh, I agree. It's just so difficult to get reliable results if the same model is sold in wildly different TDP configuration and it's results fluctuate like crazy from run to run. One good thing about M1 is that the performance is more or less stable. The Air will throttle a bit after a while, but not near as much as Tiger Lakes or Renoirs...
I think ones perspective matters a lot when it comes to Macs and gaming, and along more axis than one.
Apple iOS/iPadOS is currently the worlds largest market for games in terms of software revenue. The new Macs are quite attractive, and lacking the ability to run games under boot camp, gaming revenue on macOS is set to increase. It seems likely that this market will largely be claimed from the iOS side of things. What will those developers be able to do with the M1 providing the performance base line? There will be some Windows/console overlap as well, WoW and Baldurs Gate 3 being early out of the gate.
MacOS has never offered the widest selection of titles, thus noone buys Macs primarily to game on. It is a secondary purpose at best, and those of us who crave the AAA titles produced for Windows/consoles have always had to use alternative platforms. So now that Macs will offer very decent baseline gaming performance, the big publishers (with a couple of exceptions) have failed to nurture an audience on the platform.
There is no doubt that a couple of years down the line, Mac gaming will be in a better place than it is today. It’s only a question of just who will grab the money on the table. My gut feeling is that plucky iOS developers will be more competitive than the old game publishers. And in the context of this discussion, they are already on board with Apples GPU architecture.
No idea. AA is extremely cheap on Apple GPUs, and AF should be cheaper than on an IMR (although certainly not free). One would need to run detailed benchmarks to quantify the impact of these things.
It also makes me wonder, why SSAO and Shadows aren't free (or very low cost) on TBDR as well.
Isn't that specific to MSAA? Is FXAA or SMAA less costly on Apple GPUs?
MSAA isn't as frequent as it used to be.
Yeah it is MSAA that is "free". PowerVR says that FXAA and TAA can be costly depending on how pixel processing limited the application is.
PowerVR performance tips for Unreal Engine 4 - Imagination (imgtec.com)