Blur Busters Forums

jorimt wrote:Ah, then I'd have to test the in-game limiter up against RTSS with an upper 120 something FPS limit in the 150% resolution scenario where I can only sustain framerates in the 130s?

If so, I could do two more quick runs for confirmation.

Yes, pretty much same test you just did with the in-game limiter, but this time with RTSS.

But the in-game limiter scenario was 100% res with 141 FPS limit. The 130s uncapped/sustain framerate scenario was 150% res.

So testing RTSS against the in-game limiter in that scenario would give me the same numbers/differences in the chart I embedded in my other post.

I'm assuming I'd need to test both the in-game limiter and RTSS again with the 150% res scenario so that the in-game limiter doesn't have a lot of excess frames (low frametimes) to work with...

Oh wait, I've misread your post I thought you used 150% resolution for both capped and uncapped...

That's unfortunate. That means the results don't actually tell us the latency difference between capped and uncapped at nearly idenitcal frame rates.

The theory was that uncapped ~130FPS vs capped 130FPS would show no big latency difference in OW, but would show one in other games that don't have the latency-improving settings and tweaks OW has.

You can see now why I didn't want to deal with this specific behavior during my G-SYNC tests; it a convoluted, variable mess

I will retest the 150% in-game limiter and RTSS limiter scenarios with sustained framerates in the 130s, but capped to 120s, and post the results.

Okay, the results are in...

150% internal res was set, which allowed the test scene to hover in the mid to high 130s, with a 135 average. I set both the in-game and RTSS FPS limiter to 130, and tested them each.

The first result below is the previous uncapped test to compare the new tests with as a baseline. I did not test MPRF default/1 this time, as we've already established it makes no difference in this game.

G-SYNC + V-SYNC + mid to high 130s Uncapped + MPRF Default:
MIN: 35
AVG: 38
MAX: 41

G-SYNC + V-SYNC + 130 FPS In-game FPS Limit + MPRF Default:
MIN: 23
AVG: 28
MAX: 33

G-SYNC + V-SYNC + 130 FPS RTSS FPS Limit + MPRF Default:
MIN: 30
AVG: 33
MAX: 40

So in-game appears to have a 1-2 frame reduction (little over 1 1/2 frame average) compared to uncapped at the same framerate, and RTSS 0-1 frame reduction (nearly 1 frame average).

I'm certain this can vary depending on the given game, system, and sustained framerate at any given point.

It looks like from these tests, much like Fast Sync's third buffer utilizes the excess frames to reduce input latency/delivery time, good in-game limiters do the same thing, just at an earlier point in the input latency chain. Thus an optimal G-SYNC setup in any game would be to have frames above/well above the refresh rate, and cap 3 FPS below the refresh rate with an in-game limiter.

Awesome! Thanks for doing these. The in-game limiter still wins. I suspected the in-game limiter would get closer and closer to RTSS in this scenario, but that clearly isn't the case. It still pulls out a latency reduction out of (seemingly) thin air. No idea why in this case

I hope this makes the RTSS author consider adding the "constant throttling" option in the future. When FPS starts getting low, that's exactly when you want to reduce latency. High FPS, even uncapped is fine due to low frame times. Once your FPS gets low, you'd want a frame cap even more there than you do in high FPS situations...

jorimt wrote:It looks like from these tests, much like Fast Sync's third buffer utilizes the excess frames to reduce input latency/delivery time, good in-game limiters do the same thing, just at an earlier point in the input latency chain. Thus an optimal G-SYNC setup in any game would be to have frames above/well above the refresh rate, and cap 3 FPS below the refresh rate with an in-game limiter.

Yep. This has been done in an open source Quake engine I think to implement 0-latency vsync. The game ran at 1000+FPS uncapped (even more; it's an old game), so the dev team utilized the <1ms render times to reduce vsync input lag to extremely low levels.

Glad to do them (it answers a few lingering questions of my own), and it validates your theory more than it doesn't.

As for MPRF, we can likely project the exact same scenarios as I last posted between uncapped/in-game/RTSS, but add or remove a couple of frames of delay across the board depending on the internal MPRF value of the given game.

One last point:

jorimt wrote:It looks like from these tests, much like Fast Sync's third buffer utilizes the excess frames to reduce input latency/delivery time, good in-game limiters do the same thing, just at an earlier point in the input latency chain. Thus an optimal G-SYNC setup in any game would be to have frames above/well above the refresh rate, and cap 3 FPS below the refresh rate with an in-game limiter.

It should be noted that in-game limiters don't actually have to render the excess frames, unlike fast sync. With fast sync, it renders frames constantly; it brute-forces the issue to find out when the best render-start-time would be by actually trying as many render-start-times as possible, and the only way to do that is running the game with vsync off.

An in-game limiter can know when a good render-start-time would be without actually having to render anything.

Take it easy on Jorim. We need him to create additional content!

Do you know how hard and laborious it is to analyze over 5000 different lag samples (frame-counting sessions in high speed video!) Every single time, frame-count between a LED flash & screen activity -- then rinse and repeat -- 5080 times.

The arrival of the first 240Hz monitor is a Blur Busters special moment, warranting such unusually intense testing that will not be repeated manually.

So take it easy. Pretty please.

RealNC wrote:An in-game limiter can know when a good render-start-time would be without actually having to render anything.

Yep. Good predictive just-in-time rendering can do that. And the programmer has to do a good job of doing predictive rendering properly.

That said, for non-VRR displays, there is an immense lag penalty for a missed VSYNC.

Fast Sync (ala "low lag triple buffering technique") avoids that risk at a great penalty (rendering huge numbers of never-displayed frames, "just in case") without needing the game to support any predictive just-in-time rendering.

Already said before, but in another 'related' perspective, capped GSYNC/FreeSync is very forgiving while being low lag -- early/late frames have the potential to be displayed immediately anyway. With enough headroom (e.g. 138fps at 144Hz) there's plenty of margin for frametimes to be early/late and there's practically never such a thing as a "too late to be on time for VSYNC". In other words, frame-capped VRR is almost the ideal "low-lag VSYNC ON" experience.

Various low-latency "VSYNC ON" options:
Predictive rendering: Works on all displays. Last minute just-in-time rendering. Efficient. But stutters if render times are mis-predicted
Fast Sync: Works on all displays. Inefficient. Microstutters from fps-vs-Hz mismatch. Less microstutter the higher framerate is.
Capped GSYNC/FreeSync: Requires said VRR display. Efficient. So far, the ultimate low-lag "VSYNC ON" experience. (If not using strobing)