NVIDIA Fast Sync

Everything about latency. Tips, testing methods, mouse lag, display lag, game engine lag, network lag, whole input lag chain, VSYNC OFF vs VSYNC ON, and more! Input Lag Articles on Blur Busters.
User avatar
RealNC
Site Admin
Posts: 3740
Joined: 24 Dec 2013, 18:32
Contact:

Re: NVIDIA Fast Sync

Post by RealNC » 29 May 2016, 13:20

OK, now you made me wanna go to ebay and buy all the retro stuff I don't have anymore just to test this... Must resist the urge... :lol:

If they can get rid of the timing issues and thus eliminate micro-stutter, fast sync will be an incredibly useful option. There is really no reason why there would be any stutter if a game can consistently keep a framerate that's an exact multiple of the refresh rate. But it seems the driver just doesn't get the timing right currently. I guess they wanted to get the feature out as quickly as possible for the Pascal launch, and it's not really fleshed out yet.
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.

Sparky
Posts: 682
Joined: 15 Jan 2014, 02:29

Re: NVIDIA Fast Sync

Post by Sparky » 29 May 2016, 14:17

RealNC wrote:There is really no reason why there would be any stutter if a game can consistently keep a framerate that's an exact multiple of the refresh rate.
If you can do that, why not just keep a framerate at exactly the refresh rate?

Ultimately, you need a refresh rate synchronous framerate cap to get v-sync without latency, stutter or VRR, and that's what I was hoping for when all we had to go on was rumors.

Maximus_Fleximus
Posts: 7
Joined: 12 Jul 2015, 15:03

Re: NVIDIA Fast Sync

Post by Maximus_Fleximus » 29 May 2016, 14:17

What's the difference between Fast Sync, and simply capping your framerate in the game's console ??

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

Re: NVIDIA Fast Sync

Post by RealNC » 29 May 2016, 16:50

Sparky wrote:If you can do that, why not just keep a framerate at exactly the refresh rate?
That's just normal vsync, with huge input lag.
Ultimately, you need a refresh rate synchronous framerate cap to get v-sync without latency, stutter or VRR, and that's what I was hoping for when all we had to go on was rumors.
I assumed that's how fast sync works. Games that offer their own FPS OSD (because an external one doesn't get the right info with fast sync) shows that the game engine produces frames at rates that are multiples of the refresh rate. CS:GO and Elite Dangerous have such in-game FPS indicators, and in both what I observe is they never render at anything else than 60/120/180/240/etc FPS (an external FPS indicator, like RTSS, show FPS values that don't match the in-game indicator.) So fast sync does seem to try and do exactly that, but still fails to produce stutter-free output. It works for 5-6 seconds, and then it poops out for 1 or 2 seconds. I just assume the driver doesn't get the timing right.

Ideally, you would then cap to, say, 180FPS, and always get a constant input latency and never any stutter. But it just doesn't work right as of now.
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
RealNC
Site Admin
Posts: 3740
Joined: 24 Dec 2013, 18:32
Contact:

Re: NVIDIA Fast Sync

Post by RealNC » 29 May 2016, 16:55

Maximus_Fleximus wrote:What's the difference between Fast Sync, and simply capping your framerate in the game's console ??
Tearing. Fast sync is there to lower input lag while still having vsync.
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.

Sparky
Posts: 682
Joined: 15 Jan 2014, 02:29

Re: NVIDIA Fast Sync

Post by Sparky » 29 May 2016, 17:43

RealNC wrote:
Sparky wrote:If you can do that, why not just keep a framerate at exactly the refresh rate?
That's just normal vsync, with huge input lag.
Ultimately, you need a refresh rate synchronous framerate cap to get v-sync without latency, stutter or VRR, and that's what I was hoping for when all we had to go on was rumors.
I assumed that's how fast sync works.
I wish, but nope. All fast sync does differently is drop frames instead of restricting framerate with backpressure.
Games that offer their own FPS OSD (because an external one doesn't get the right info with fast sync) shows that the game engine produces frames at rates that are multiples of the refresh rate. CS:GO and Elite Dangerous have such in-game FPS indicators, and in both what I observe is they never render at anything else than 60/120/180/240/etc FPS (an external FPS indicator, like RTSS, show FPS values that don't match the in-game indicator.) So fast sync does seem to try and do exactly that, but still fails to produce stutter-free output. It works for 5-6 seconds, and then it poops out for 1 or 2 seconds. I just assume the driver doesn't get the timing right.
You're either dropping or gaining one frame every 5-6 seconds. (just like this, except it sounds like you have more frametime variance, so you'll make several jumps up and down at each big transition instead of just one(ignore the high frequency noise, that's caused by random click timing, not the game engine): http://i.imgur.com/lwGn6t3.png)

To obtain the ideal solution, you need two signals from the GPU driver back into the game engine, one is a v_blank signal, and the other is a frame completion signal. From that you can keep track of how long it takes an individual frame to render, how consistent that time is, and how much time there is between the frame finishing rendering and actually getting displayed. This means you can make a precise tradeoff in latency vs confidence in rendering on time. Say a frame takes 3ms±1ms to render, if your refresh rate is 60hz, you would set your cap to get user input and start working on a frame about 12ms after the most recent v_blank, then wait until 12ms after the next v_blank. There isn't any reason to render extra frames, because you're just going to throw those away anyway. You get rid of the latency caused by buffering in the render chain by only ever allowing one frame into the render pipeline at a time(or two, if you need the extra buffering to deal with your frametime variance)

This would get you perfectly smooth animation with approx 7ms of full chain latency(excluding monitor, unless you're using a CRT).

Anyway, that's not what fast sync does, at least according to Nvidia:

https://www.youtube.com/watch?v=WpUX8ZNkn2U

If fast sync is operating as described in that video, the game engine should be able to run at any framerate, not just a multiple of your refresh rate, and you'll get judder proportional to 1/framerate.

If there is a separate framerate cap somewhere, that would explain your hitch every few seconds.

stirner
Posts: 74
Joined: 07 Aug 2014, 04:55

Re: NVIDIA Fast Sync

Post by stirner » 30 May 2016, 07:59

Capping framerate just below refresh rate with VSync already gives you tearing-free low-latency gameplay. Triple-buffered if need be. Now obviously "FastSync" is aimed at getting high framerates, but it's not like CS:GO engine-wise benefits significantly from framerates above tickrate. And so if you can get your monitor to 129+Hz, the solution already exists if you hate tearing/want a more consistent animation.

Is there any advantage to FastSync as opposed to just doing that?

Sparky
Posts: 682
Joined: 15 Jan 2014, 02:29

Re: NVIDIA Fast Sync

Post by Sparky » 30 May 2016, 09:41

stirner wrote:Capping framerate just below refresh rate with VSync already gives you tearing-free low-latency gameplay. Triple-buffered if need be. Now obviously "FastSync" is aimed at getting high framerates, but it's not like CS:GO engine-wise benefits significantly from framerates above tickrate. And so if you can get your monitor to 129+Hz, the solution already exists if you hate tearing/want a more consistent animation.

Is there any advantage to FastSync as opposed to just doing that?
Yes, because the camera direction is updated with framerate, not tickrate, so you get better animation and feedback on your inputs.

Capping framerate asynchronously will give you either 1/framerate or 1/refresh rate of judder(whichever is less). If you can maintain framerate=refresh rate, doubling framerate will cut judder in half, and will decrease full chain latency by about 6ms on average(assuming you're using fast sync or fullscreen windowed).

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

Re: NVIDIA Fast Sync

Post by RealNC » 30 May 2016, 10:21

stirner wrote:Capping framerate just below refresh rate with VSync already gives you tearing-free low-latency gameplay.
But it stutters. And that's annoying.
Now obviously "FastSync" is aimed at getting high framerates, but it's not like CS:GO engine-wise benefits significantly from framerates above tickrate.
This is not CS:GO specific. Every game feels more fun when the mouse feels less like a boat when you look around.
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.

Trip
Posts: 157
Joined: 23 Apr 2014, 15:44

Re: NVIDIA Fast Sync

Post by Trip » 30 May 2016, 15:54

Tickrate doesnt effect the mouse movement in any way as far as I know. Which is what most people experience as a game being smooth. If you have higher framerates then the tickrate it wont affect hit registration or your reaction times. But it does improve your ability to aim albeit slightly. In the case of fast sync it decreases latency the higher it is so in that case it helps you with reaction times as well although I doubt anyone would use fast sync over no vsync in high level matches.

Edit: Oh I just saw sparky his comment pretty much is the same thing as this.

Post Reply