How does capping framerate reduce input lag?

CaptaPraelium · Oct 6, 2018

RealNC said: ↑

@CaptaPraelium I wasn't talking about predictive limiting. Just normal limiting, and why it's beneficial in the majority of cases when you play GPU-bound games.
Click to expand...

Yeh I understood that. I used that quote in context of the discussion we were having (regarding the benefit of capping framerate in a manner that causes 'synchronous' rendering, versus just using MPRF 1 and allowing the CPU to render frames while the GPU is busy). The quote system on this forum is very tidy but makes it hard to follow extended conversations. Let's see if I can put it all together? :/ 2nd time maybe?? lol 3rd times the charm??? XD

CaptaPraelium said: ↑

Even still, it would have the negative impact of reducing to as much as halving your framerate since the CPU is not allowed to do its work while the GPU is busy, so now the GPU will have to wait for the CPU to prepare (pre-render) the frame before it can carry on....but of course, there's this:

RealNC said: ↑

But remember that if the FPS cap is reached, you're there already, you don't need more FPS
Click to expand...

So if you can always maintain a framerate above the cap you want then it's always good. If you're dipping below the cap, then MPRF 1 will take care of ensuring no additional pre-rendered frames.
Click to expand...

RealNC said: ↑

The issue is that dipping below the cap happens for a reason. If that reason is a GPU bottleneck, then you get the sudden input lag increase.
Click to expand...

CaptaPraelium said: ↑

Since you're capped at a framerate approaching half the framerate the card is capable of (as a result of synchronous operation), this would require a sudden jump in GPU frametime for that frame, approaching double what you've capped it to. This is a stutter anyway and a problem that should be fixed elsewhere.
Click to expand...

Point of this is to answer OPs question about why limiting the framerate AND MPRF 1 have a different effect to just one or the other.

mdrejhon · Oct 31, 2018

I have a relevant post I made at wccftech that deserves a crosspost here, because it explains how caps can reduce input lag on a variable refresh rate display -- GSYNC/FreeSync. With some programmerspeak thrown in.

For games that want to run at really high framerates, e.g. CS:GO can run 300fps VSYNC OFF. For that, it's a very low GPU render lag before it hits the monitor. 1/300sec.

However, VRR, by default, caps framerates to max Hz, for smoothness' sake. The measured extra lag is identical to VSYNC ON. This is forced capping beyond game control. Enabling VRR (with default VSYNC ON behaviour) means next frame may finish rendering but not begin displaying immediately -- because the monitor is busy still refreshing the previous refresh cycle.

The goal of a game-side cap (e.g. fps_max in CS:GO) or a before-the-drivers cap (e.g. RTSS) is to finish rendering new frames right when the monitor is idling -- doing nothing at all (e.g. not currently refreshing a refresh cycle).

A render completion colliding with a monitor still busy refreshing a previous frame (still-in-progress scanout of previous refresh cycle), means a forced wait (lag) until the monitor is ready to begin refreshing the frame.

By forcing a cap onto the game (preferably an in-game cap, but RTSS is the lowest-lag external frame rate capping utility) - it forces the game to wait until beginning the new frame. If the game is rendering faster than the currently configured display sync mode -- then it is better for the game to wait before doing an input read, followed by rendering, followed by display. The button-to-photons latency becomes smaller if you cap closer to the game before wasting time to render frames while the monitor is still busy refreshing.

With the cap, the display output is refreshing *immediately* the same microsecond as Direct3D Present() or OpenGL glutSwapBuffers(). A VRR display is an asynchronous refresh display.

Yes, true asynchronous refresh if within VRR range. The actual screen's pixels are beginning to receiving new voltages right at the time the GPU finishes rendering because frame immediately begins transmitting to the monitor over the cable. This means the first pixels can begin refreshing practically at that instant. (just only cable transmission latency, display processing latency, and GtG pixel transition latency -- there's no such thing as a "wait for next refresh cycle" latency on a VRR monitor in VRR mode). Metaphorically, it is akin to a variable-sized blanking interval. The monitor idles between refresh cycles until the software presents (which immediately begins delivery of pixels over the cable, and the monitor can begin scanning out right at that instant). Refresh cycles are not individually infinitely fast, so trying to refresh sooner than the monitor is ready -- means lag. Figuratively -- It is in the videogame's lag interests to hold off for a bit before the next "inputread+render+present" cycle, for lowest button-to-pixels lag if you want a lower framerate than your GPU's ability.

With VRR, refresh cycles timing are commanded exactly by the software call, there is no hardware metronome for VRR. As long as interval is within the VRR range, the API is nonblocking.

The beginning of the display scanout for refresh cycles for VRR display is slaving exactly to the timing of the software delivering frames. Once it begins refreshing, the monitor is "busy" for the time duration (e.g. 1/144sec) and no new Present() nor glutSwapBuffers() can generate a lagless start to a refresh cycle. Subsequent calls block. Just like VSYNC ON.

Programmerspeak: To avoid blocking/freezes during the frame presentation API call, you must throttle the rate of the API Present() or glutSwapBuffers() to a time period more than the duration of one max-Hz refresh cycle (e.g. 1/144sec) for instantaneous begin of frame transmission over the video cable to the monitor without any added lag.

Now the second part, "why do I have to cap several frames per second below" - why can't we just cap 143.9fps for 144Hz GSYNC. Theoretically it should have been possible. But our tests showed the need for a safety margin.

In addition, explaining why lag benefits don't really appear until a few frames per second below -- it's a (mostly mysterious) safety margin reliably noticed in our tests that still persists after years. We believe that there is additional stuff going on in the drivers that add some latency -- possibly a polling mechanism for monitor busy / not busy status -- that added lag if the monitor was intermittently still refreshing. myself of one of my helpers (Jorim, for this one) did high speed camera tests confirmed this in 2013 and 2017 that capping was reliably lower lag with VRR:

2013 tests - "GSYNC Preview 2" - www.blurbusters.com/gsync/preview2
2017 tests - "GSYNC 101" - www.blurbusters.com/gsync/gsync101

Make sure to quickly flip through the 14 pages of the massive 2017 tests that ended up becoming the world's biggest GSYNC test session ever, and since.

We did over 5,000 separate high speed video measurements from trigger to onscreen response, and it ended up statistically way far above noisefloor -- there were clearly reliable/easy lag savings that became a relatively simple "cap a few below". (compared to the highly fiddly low-lag VSYNC)

Yes, that's counting the number of mulliseconds between two sections in a high speed video (the mouse light, and the onscreen gunshot) for over 5,000 snippets of high speed videos! -- very labourious frame counting procedure, but this was the only way to reliably measure button-to-pixels latency for GSYNC, for so many test scenarios, for multiple runs to get reliable statistics.

The results ended up being unmistakable: Significant lag savings reliably occured with GSYNC frame rate capping. Few places on the Net have dived this deep into VRR lag optimization as we did...
Click to expand...

BlindBison · Nov 2, 2018

Thanks so much, that's helpful!

Log in or Sign up

How does capping framerate reduce input lag?

CaptaPraelium Guest

mdrejhon Member Guru

BlindBison Ancient Guru

Share This Page