If the pipeline stalls for 70ms it’s a problem even if in theory you don’t “miss” a frame you still aren’t getting new frames until rendering finishes.

All adaptive refresh rates do is avoiding unwanted delays after the frame finishes.

That's not how it works. A 70ms pipeline stall means a ~90ms frame which means that your 1% framerate low is going to be reduced.

Adaptive refresh rate means that only frame rate matters. You can't miss a frame, you can only have a frame take longer, and that's measured perfectly well by 1% or 0.1% low frame rates.

Also I don't see why an M series CPU is going to be any better at feeding the (asynchrous, multiple frames in flight) GPU rendering pipeline than a modern x86 CPU, when both are just as fast. macOS is also pretty bad at realtime scheduling for heavy workloads compared to modern Linux and Windows.

Yes occasional 90ms stall reduces 1% frame rates, but less than how annoying it is.

A 10 minute test at 120 FPS is 10 * 60 * 120 ~= 72,000 frames. Your 1% lows is an average of ~720 frames but so what if of 300 them are at 60 FPS you’re going to have trouble noticing.

While if you’re almost rock solid at 120FPS a dozen 90ms stalls it’s really obvious that something is wrong but the calculated 1% low’s actually look better.

The comparison isn’t average FPS or even 1% lows where dedicated graphics cars have an advantage, the comparison is what happens when things go very wrong. And it’s in that very specific case when they may have an advantage.

> While if you’re almost rock solid at 120FPS a dozen 70ms stalls it’s really obvious that something is wrong but the calculated 1% low’s may actually look better.

I think this is an instance of the coordinated omission problem: you cannot simply measure the latency of the frames that were completed, but instead have to consider the frames that should have been delivered during a stall. Looking at frame time percentiles means a stall only penalizes your metric with one bad frame, when it should be penalized for missing several frames and showing the user an increasingly stale image for several average-frametimes.

This isn't actually true. Looking at aveeages will in fact reflect correctly on average frame staleness over a sampling period. A single frame that's 5x too long or 4 frames that are 2x too long have the same impact on the average delta of frame staleness on the total sum.

Think of it like Little's law in queing theory , it's better to simply just look at different percentiles, like 99 or 99.9th. The average framerate correctly indicates the average staleness.

> A single frame that's 5x too long or 4 frames that are 2x too long have the same impact on the average delta of frame staleness on the total sum.

It's not clear to me: are you saying those two scenarios should be quantified as equally bad? Because it seems pretty obvious to me that the 5x outlier is qualitatively much worse.

The fact that the 5x outlier may be qualitatively worse is something that you pin down using percentiles, which is what everyone does, either 1% or 0.1% low. The argument about time-weighted frame staleness is not mathematically valid.

There’s nothing inherently mathematically special about 1% or 0.1%, you can also use 0.0042% or 0.00069% which highlights this kind of extreme outliers more.

Benchmarking sites use 1% or 0.1% because they better highlight the commodity PC hardware rather than the games bugs and architecture.

That's not true. You can't use 0.0042% because then you don't have enough frames to be statistically significant without running for a very long time. It's also true that a frame pacing issue that is so rare that it isn't even impacting the 0.1% frame time isn't going to be noticeable, really.

These benchmarks are controlled for game bugs and architecture by simply averaging over ~40-50 games, on repeatable loops.

This is a completely misguided analysis. First of all, there is nothing in the M series architecture that's going to avoid pipeline stalls, let aloe huge 70ms graphics pipeline stalls. As I've explained above, games keep multiple frame pipelines in flight at once, so you don't have these kind of issues unless there is a scheduling or I/O issue. There is no advantage here.

The only advantage is that the transfer from GPU to CPU is faster in terms of latency. This doesn't cause pipeline stalls, because as I've explained above, frames are kept in flight, so latency is not critical. At the same time, modern CPU-GPU interconnects have similar bandwidth to RAM.

Additionally, you're not the first person to have thought about frame pacing. Dozens of reviewers have full frame pacing graphs with the frame times of every frame, as well as 0.1% lows, and we simply don't see what you're describing. 100ms+ frames are not a problem on modern games and modern hardware, and when they are, it's because of some blocking read to storage or to some scheduling issue, not because of CPU/GPU speed.

The impact of link speed on 0.1% low framerates has already been investigated, and it's minimal, and there isn't even an advantage here.

> 100ms+ frames are not a problem on modern games and modern hardware, and when they are

So, you actually acknowledge that this stuff happens and 1% lows doesn’t track them properly. I can only assume you’re arguing in bad faith at this point.

There’s many causes of this stuff beyond disk IO which I can give examples for but I don’t want to get into it.

> 100ms+ frames are not a problem on modern games and modern hardware, and when they are

There’s a multitude of such bugs which ship with modern titles. Benchmarking sites don’t use the release day build of 2077 for very good reasons.

That's a problem with release day video games being unfinished buggy messes, not something that's going to change with hardware.