jorimt wrote:To be clear, does the behavior you describe occur only when you have an FPS limit in place and aren't hitting it, or does it also occur at any framerate below the refresh rate without an FPS limit applied and MPR set to anything other than "1"?
It occurs with and without a frame limiter. If a game renders at, say 95FPS, input lag is the same regardless of whether you limit FPS to 141 or not at all.
This is also a bit counter-intuitive to the "RTSS adds up to 1 frame of latency" statement. In this scenario, RTSS will REDUCE input lag, not INCREASE it if you cap the game to 94FPS.
However, this should only be a side-note, as it does have nothing to do with g-sync (which is the article's subject matter.) It is however, a very useful fact for people who want the most lag-free experience they can get. Even if you don't use g-sync and play with vsync OFF, RTSS will reduce input lag by making sure the game gets frame capped.
It's weird, I know, but it's what seems to happen with the majority of single player games. Games tuned for latency (like CS:GO and OW) don't seem to follow this pattern. Games like Witcher 3, Fallout (all of them), Deux EX, you name it, are exhibiting this behavior.
The technical details behind this seem to be related to single-player games not trying to keep any kind of synchronization between CPU and GPU. The "pre-render frames" mechanism is inherently an asynchronous concept, and thus render or frame presentation or buffer flip operations seem to get queued even with vsync off. When using frame limiting, even with RTSS, it would seem that things become synchronous; only one operation is in the queue, which basically means it's synchronous; the game is blocked from doing anything further until the single queued operation is completed.
Someone with more experience with the D3D or GL APIs would most probably have some insight to give here.
I also have to wonder if a frame limiter like RTSS could be modified in such a way that it behaves as if the frame cap is always reached, regardless of what you set it to. For example by blocking at the Present() function call (D3D) regardless of whether the frame time is lower than the target time or not. I looked for any open source frame limiters out there that I could use to experiment with this, but there don't seem to be any
), is whether MPRF 1 when not hitting the cap gives as low input lag as MPRF 1 + cap. If not, meaning MPRF 1 (the best that can be done) has higher input lag than capped frame rate, then that's kind of huge news for people who prefer the lowest latency possible, even it means giving up some extra FPS. And it means RTSS (and other cappers) have a big opportunity here to introduce a latency reducing mode that knows how to make the game always hit a cap, (a new "dynamic/adaptive" cap; probably a fixed frame time offset regardless of current FPS (again, an open source limiter would have allowed me to do this myself, but, well.)
