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.
Trip
Posts: 157
Joined: 23 Apr 2014, 15:44

Re: NVIDIA Fast Sync

Post by Trip » 30 May 2016, 16:08

Sparky wrote:If there is a separate framerate cap somewhere, that would explain your hitch every few seconds.
Silk smoothness confirmed?
https://www.youtube.com/watch?v=WpUX8ZNkn2U
At 10:10 someone asked a question about it.

I thought it was a way to cap the amount of thrown away frames. They might have it capped in a specific profile or something?

microsista
Posts: 3
Joined: 31 May 2016, 01:02

Re: NVIDIA Fast Sync

Post by microsista » 31 May 2016, 01:06

there is no way fast sync is possible without motion judder from variable framerate, i see that they try to cap it at multiples of the refresh-rate like 60-120-180, but refreshrate of the monitor is not always 60hz, but sometimes 59.9 and sometimes 60.1, so there is no way to get exactly multiples of the refresh-rate without getting this information from the monitor every frame, and that is what regular v-sync does, and it causes input lag

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

Re: NVIDIA Fast Sync

Post by Sparky » 31 May 2016, 01:43

microsista wrote:and that is what regular v-sync does, and it causes input lag
A bit of clarification, v-sync causes so much input lag because of where in the render pipeline it restricts framerate, not just because it's synchronized to the monitor. It's certainly possible to implement v-sync with significantly less input lag, as described earlier in this thread, even if you don't increase the framerate.

microsista
Posts: 3
Joined: 31 May 2016, 01:02

Re: NVIDIA Fast Sync

Post by microsista » 31 May 2016, 03:51

Sparky wrote: A bit of clarification, v-sync causes so much input lag because of where in the render pipeline it restricts framerate, not just because it's synchronized to the monitor.
yes, but if you dont restrict the framerate in the back of the render pipeline to exactly the refresh rate to the monitor you will have animation judder which is what i said
Sparky wrote: It's certainly possible to implement v-sync with significantly less input lag, as described earlier in this thread, even if you don't increase the framerate.
i've read the whole thread and haven't found it (assuming you dont want stutter/animation judder)

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

Re: NVIDIA Fast Sync

Post by stirner » 31 May 2016, 10:59

Sparky wrote:Yes, because the camera direction is updated with framerate, not tickrate, so you get better animation and feedback on your inputs.
Obviously, but FastSync discards excess frames, right? And so you will only get a refresh amount of frames anyways. Doesn't really make a large latency difference whether that amount is achieved with a cap or by throwing frames away after the fact, does it? Besides, 128fps is more than enough in terms of update intervals/latency, considering decades of competitive FPS have been played on 100/125fps. Obviously more is better, but I'd always prefer a stable sufficient rate.
Sparky wrote: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).
I never found this too noticeable at all. That's one judder per second, but otherwise you get very precisely timed frames, i. e. a very consistent animation (as opposed to tearing and frame frequency affecting the animation throughout without VSync - microstuttering).

But I get that FastSync has an advantage there. Fullscreen windowed though? You mean forcing the DWM to handle the game? Which is not VSync but essentially the same as FastSync, right? Only allowing full frames to be drawn.
RealNC wrote:But it stutters. And that's annoying.
I obviously don't play with it and so I can't say I have the experience to say otherwise, but from my time playing around with it there was no noticeable stutter. Plus it's a once-per-second thing that also occurs in a predictable fashion. As long as you can precisely keep the framerate up that is, of course.
RealNC wrote:This is not CS:GO specific. Every game feels more fun when the mouse feels less like a boat when you look around.
At 128+fps no game's input feels like a boat.

I personally cap at 128fps (without VSync) and it is plenty. I get that "more is better", but not only does FastSync apparently discard excess frames (I get there's still a latency difference to a capped framerate), but it's not like there's a noteworthy advantage to framerates above 128fps either. Things get marginally smoother and latency is marginally less, but I keep 2.0 ratios in DM with 128fps (@128Hz) and didn't notice improvements when I uncapped framerate (or increased refresh for that matter). 128 as per tickrate is what you should always have to be competitive, and I know more is always better even in terms of netcode too (runs smoother and no risk of dropping frames and thus missing packets), but I prefer rock-stable (0.00var) framerates and like I said, 128fps is plenty.
Trip wrote: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.
Tickrate indeed doesn't affect your input rendering as that is predicted, but FastSync discards frames anyway and so the actual latency difference between Xfps capped and Xfps "adjusted" from Yfps is not simply Xfps vs. Yfps. And high framerates do help with reactions times and stuff since latency (both input and output) decreases. But that's pretty marginal; 100fps vs. 1000fps is a 9ms difference. Not a big deal when you consider reaction times being on average in the 200ms region. Yes, latency stacks, but framerate is not where you will make the biggest diference there, and I wouldn't want to sacrifize stable frame frequency and a consistent world animation for a few milliseconds less latency.

That said, for competitive purposes just not using VSync/GSync/FastSync/WhateverSync is obviously the way to go. You don't even notice tearing in fast-paced FPS, especially when you are at multiples of refresh or just have high FPS.
For everything else I'd have to see FastSync in action, but to me VSync + cap just below refresh seemed pretty stellar given you have a 120+Hz monitor and a machine that can keep the capped framerate stable.

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

Re: NVIDIA Fast Sync

Post by Sparky » 31 May 2016, 13:40

microsista wrote:
Sparky wrote: A bit of clarification, v-sync causes so much input lag because of where in the render pipeline it restricts framerate, not just because it's synchronized to the monitor.
yes, but if you dont restrict the framerate in the back of the render pipeline to exactly the refresh rate to the monitor you will have animation judder which is what i said
Sparky wrote: It's certainly possible to implement v-sync with significantly less input lag, as described earlier in this thread, even if you don't increase the framerate.
i've read the whole thread and haven't found it (assuming you dont want stutter/animation judder)
In addition to v-sync you add a second (synchronous) framerate cap, in the game engine, so you never run ahead or fall behind, and avoid excessive buffering. (you can control exactly the amount of buffering you introduce, and keep it just high enough to cover your frametime variance.
stirner wrote: Obviously, but FastSync discards excess frames, right? And so you will only get a refresh amount of frames anyways. Doesn't really make a large latency difference whether that amount is achieved with a cap or by throwing frames away after the fact, does it? Besides, 128fps is more than enough in terms of update intervals/latency, considering decades of competitive FPS have been played on 100/125fps. Obviously more is better, but I'd always prefer a stable sufficient rate.
it does make a difference, about 13ms of difference if you're comparing fullscreen windowed or fast sync on a 60hz monitor at 60fps vs 300fps in game framerate cap. For a 128hz monitor there'd be about 3ms difference between 128fps and 300fps. The difference gets bigger if you're using an external or driver based framerate limit. It's not just a flat change in latency either, it's reducing the inconsistency in latency.
Last edited by Sparky on 31 May 2016, 13:42, edited 1 time in total.

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

Re: NVIDIA Fast Sync

Post by RealNC » 31 May 2016, 13:42

microsista wrote:there is no way fast sync is possible without motion judder from variable framerate, i see that they try to cap it at multiples of the refresh-rate like 60-120-180, but refreshrate of the monitor is not always 60hz, but sometimes 59.9 and sometimes 60.1, so there is no way to get exactly multiples of the refresh-rate without getting this information from the monitor every frame, and that is what regular v-sync does, and it causes input lag
Nah. When I cap to exactly 60FPS with a mode of 60.002Hz, it works just fine. Sure, there may be one skipped frame every 10 seconds or so, but that's inconsequential.

I do believe that if nvidia get the timing exactly right, fast sync should be able to produce judder-free results.
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: 3737
Joined: 24 Dec 2013, 18:32
Contact:

Re: NVIDIA Fast Sync

Post by RealNC » 31 May 2016, 13:55

stirner wrote:
RealNC wrote:This is not CS:GO specific. Every game feels more fun when the mouse feels less like a boat when you look around.
At 128+fps no game's input feels like a boat.

I personally cap at 128fps (without VSync) and it is plenty.
I'm referring to vsync on here. With vsync off, there's never any input lag for me either. Not just at 120FPS, but also at 60FPS. Even at 30FPS it's fine (except it's unplayable for me due to stutter and blur.)

But as soon as you enable vsync, you get a floaty mouse in most games. There's been a few games that have some sort of "low latency vsync", but not many (the only one I'm aware of was Alan Wake.) Developers just don't seem to care at all about the issue. Their engines just seem to fill up frame buffers with 100+ms worth of output frames with no attempt to reduce that.
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.

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

Re: NVIDIA Fast Sync

Post by stirner » 03 Jun 2016, 19:23

Sparky wrote:it does make a difference, about 13ms of difference if you're comparing fullscreen windowed or fast sync on a 60hz monitor at 60fps vs 300fps in game framerate cap. For a 128hz monitor there'd be about 3ms difference between 128fps and 300fps. The difference gets bigger if you're using an external or driver based framerate limit. It's not just a flat change in latency either, it's reducing the inconsistency in latency.
With FastSync you get 1 frame per refresh, right? So the renderer is going at 300fps, but your effective latency is still determined by the refresh cycle. Which, yes, if the renderer is working faster and frames merely discarded afterwards (as opposed to throttling the renderer at some stage like a cap does) that still makes a latency difference, but not linearly?
RealNC wrote:I'm referring to vsync on here. With vsync off, there's never any input lag for me either. Not just at 120FPS, but also at 60FPS. Even at 30FPS it's fine (except it's unplayable for me due to stutter and blur.)

But as soon as you enable vsync, you get a floaty mouse in most games. There's been a few games that have some sort of "low latency vsync", but not many (the only one I'm aware of was Alan Wake.) Developers just don't seem to care at all about the issue. Their engines just seem to fill up frame buffers with 100+ms worth of output frames with no attempt to reduce that.
Obviously, but VSync with a cap means VSync-induced latency is only half a refresh (basically you lose the information teared frames introduce). Which at 120+Hz is more than bearable and not boat-y at all. Am I missing something where it has more latency somehow? I vaguely remember Sparky's tests, but the results seemed off and counter-intuitive (latency for capped VSync was higher than just VSync at times) and obviously those results include on average the one frame that will be shown twice in a second.

Either way, for a not-too-competitive FPS experience this method has always seemed great to me. The increase in latency is noticeable, but it's slight and arguably negligible at 120+Hz.

And FastSync is limited to NVIDIA's new-gen cards, isn't it?

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

Re: NVIDIA Fast Sync

Post by Sparky » 03 Jun 2016, 20:29

stirner wrote:
Sparky wrote:it does make a difference, about 13ms of difference if you're comparing fullscreen windowed or fast sync on a 60hz monitor at 60fps vs 300fps in game framerate cap. For a 128hz monitor there'd be about 3ms difference between 128fps and 300fps. The difference gets bigger if you're using an external or driver based framerate limit. It's not just a flat change in latency either, it's reducing the inconsistency in latency.
With FastSync you get 1 frame per refresh, right? So the renderer is going at 300fps, but your effective latency is still determined by the refresh cycle. Which, yes, if the renderer is working faster and frames merely discarded afterwards (as opposed to throttling the renderer at some stage like a cap does) that still makes a latency difference, but not linearly?
Well, there are several different things that impact input lag, so no, it's not all linear, but much of it is proportional to the time between rendered frames.
RealNC wrote:I'm referring to vsync on here. With vsync off, there's never any input lag for me either. Not just at 120FPS, but also at 60FPS. Even at 30FPS it's fine (except it's unplayable for me due to stutter and blur.)

But as soon as you enable vsync, you get a floaty mouse in most games. There's been a few games that have some sort of "low latency vsync", but not many (the only one I'm aware of was Alan Wake.) Developers just don't seem to care at all about the issue. Their engines just seem to fill up frame buffers with 100+ms worth of output frames with no attempt to reduce that.
Obviously, but VSync with a cap means VSync-induced latency is only half a refresh (basically you lose the information teared frames introduce). Which at 120+Hz is more than bearable and not boat-y at all. Am I missing something where it has more latency somehow? I vaguely remember Sparky's tests, but the results seemed off and counter-intuitive (latency for capped VSync was higher than just VSync at times) and obviously those results include on average the one frame that will be shown twice in a second.
I think you misunderstood something. Input to output latency is always lower for capped(because uncapped v-sync adds buffering), but the variance in latency is higher because the cap isn't synchronized to refresh rate: http://i.imgur.com/lwGn6t3.png. So the average latency increases by half a frame, but the maximum latency increases by a full frame when you go from capped v-sync off to capped v-sync.

Either way, for a not-too-competitive FPS experience this method has always seemed great to me. The increase in latency is noticeable, but it's slight and arguably negligible at 120+Hz.

And FastSync is limited to NVIDIA's new-gen cards, isn't it?
Nope. That's at least going to be added to Maxwell, and possibly Kepler too. Can also use fullscreen windowed.

Post Reply