G-sync + V-sync (Frametime stabilization)

Talk about NVIDIA G-SYNC, a variable refresh rate (VRR) technology. G-SYNC eliminates stutters, tearing, and reduces input lag. List of G-SYNC Monitors.
Post Reply
MT_
Posts: 113
Joined: 17 Jan 2017, 15:39

G-sync + V-sync (Frametime stabilization)

Post by MT_ » 17 Jan 2017, 15:43

Hi there.

I'm a bit confused about how V-sync combined with G-sync enabled the frametime stabilization.

I'm playing a game where tracking the crosshair is important, and with V-sync on it seems easier to keep a stable tracking and it seems i can shoot more accurately.

So is it true that V-sync alone, even without G-sync has inherent frametime stabilization by nature?

Also, another question is.. Does it add any additional input latency? Assuming I run G-sync properly with fps cap?

Can anyone shed some extra light on this? THanks!

Edit: Sorry, Think I found a very well explained thread at http://forums.blurbusters.com/viewtopic.php?f=5&t=3073
Thanks anyway!
LTSC 21H2 Post-install Script
https://github.com/Marctraider/LiveScript-LTSC-21H2

System: MSI Z390 MEG Ace - 2080 Super (300W mod) - 9900K 5GHz Fixed Core (De-lid) - 32GB DDR3-3733-CL18 - Xonar Essence STX II

User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: G-sync + V-sync (Frametime stabilization)

Post by Chief Blur Buster » 25 Jan 2017, 10:42

VSYNC ON does input lag, though it does stable frame times by its own nature -- the VSYNC timing forces a fixed wait-time period regardless of frame times. So it kinds of acts as a metronome on when the input reads & GPU renders occurs -- but adds an input lag penalty.

There are ways to massively lower latency while keeping frametimes stable -- and that's the utilization of a good framerate cap in certain games. For example, Source engine games have a fps_max setting available -- that in itself also stabilizes some latency fluctuations between input reads & display of frames, without the added input lag of VSYNC ON. Though mind you, VSYNC ON has other casual advantages (although not good enough to be applicable to many professional competition gamers, due to the lag) -- VSYNC ON makes strobed modes much smoother.

jorimt's thread is excellent read, too!
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

User avatar
RealNC
Site Admin
Posts: 3740
Joined: 24 Dec 2013, 18:32
Contact:

Re: G-sync + V-sync (Frametime stabilization)

Post by RealNC » 27 Jan 2017, 07:52

Chief Blur Buster wrote:VSYNC ON does input lag, though it does stable frame times by its own nature -- the VSYNC timing forces a fixed wait-time period regardless of frame times.
Are you 100% sure on that one? There's many games out there that seem to render more frames while the current frame is still waiting for the vblank. What then happens is that those frames are pilling up in buffers. Furthermore, they are rendered as fast as possible, until all buffers are filled.

You get a boost of frames rendered with very low frame times, then they sit there waiting to be scanned out in order while the game doesn't render anything anymore (since the buffers filles.) So you get a bunch of frames that took like 10ms to render, then nothing, then another bunch of 10ms frames. They are all presented at 16.7ms intervals (vsync.)

The end result of that seems to be atrocious micro-stutter and a multiple of 16.7ms worth of input lag (100ms is not uncommon.) See Fallout 4.

It seems to me that the only way to actually force a fixed wait-time period is to use a frame limiter, which unlike vsync actually blocks the game from rendering more frames.
SteamGitHubStack Overflow
The views and opinions expressed in my posts are my own and do not necessarily reflect the official policy or position of Blur Busters.

User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: G-sync + V-sync (Frametime stabilization)

Post by Chief Blur Buster » 27 Jan 2017, 12:48

RealNC wrote:
Chief Blur Buster wrote:VSYNC ON does input lag, though it does stable frame times by its own nature -- the VSYNC timing forces a fixed wait-time period regardless of frame times.
Are you 100% sure on that one? There's many games out there that seem to render more frames while the current frame is still waiting for the vblank. What then happens is that those frames are pilling up in buffers. Furthermore, they are rendered as fast as possible, until all buffers are filled.
I think we're both right, "depending":

AFAIK -- turn off multicore rendering in Source engine games, and you should get fixed-latency input reads in Source engine games during VSYNC ON. Or even, in much older games such as GLQuake.

It certianly varies from game to game. But clean double-buffered-ONLY VSYNC (no extra buffers) with input reads occuring right after page flips, ideally serve to create a fixed latency, by providing the metronome of input reads. If it's done in this cycle: Input read [instant], Render frame [takes time], Wait for vsync [takes time], Display rendered frame [instant], rinse and repeat -- input reads then practically occurs at the same time as VSYNC. So in this case, you have a predictable fixed lag, even if more laggy. But if the input read (i.e. in another thread) occurs immediately after the render, but before waiting for VSYNC, then the latency of input reads would jitter around depending on frame render times -- despite having a fixed framerate! Varying input lag at a fixed framerate is more annoying than a slightly larger but fixed (stationary) input lag.

Even if you're at 60fps, input lag that vary in a 1/60sec window, can throw off aiming -- people can compensate more easily for a predictable fixed lag (e.g. the "predictable lag" of steering wheel response in racing games). Varying input lag is much easier to see when a game suddenly flips between 30fps and 60fps, but varying input lag can still occur even at a fixed framerate. The higher the framerate (e.g. 120fps@120Hz) the input lag variance window during consistent framerates, would be smaller (a 1/120sec variance window), but can still be noticed. The varying input lag behavior is a bigger problem at 60fps.

I wonder if any framerate limiters does creative methods of rendertime-lengthening (e.g. slows down rendering of fast-to-render frames) as an alternative workaround for those particular games.

There are occasional situations (not at FPS tournaments though!) where slightly more input lag is desired to make the input lag fixed/predictable/consistent.

In car racing games the steering wheel is naturally laggy like a real car, but at least it is a predictable lag, and you can train yourself to it. It's when the lag varies that it's harder to train to.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

Post Reply