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.
stirner
Posts: 74
Joined: 07 Aug 2014, 04:55

Re: NVIDIA Fast Sync

Post by stirner » 04 Jun 2016, 03:56

Sparky wrote: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.
So say I have 101Hz VSync'd @ 100fps capped. The latency difference to 100Hz FastSync'd @ 300fps won't be ~6.6ms as the framerates would determine, will it? Since effective framerate for the latter scenario still is 100fps, just that some of those 100 frames will contain slightly fresher data than the 100 frames in a capped scenario would.
Sparky wrote: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.
Yeah that makes more sense. I was referring your old results that I think didn't quite paint the same picture. Latency being lower because you cut the buffer is what I assumed, and so those results were counter-intuitive (and counter-empirical) to me back then (http://forums.blurbusters.com/viewtopic ... &start=270). But you did say it could have had to do with quirks of your setup.
Sparky wrote:Nope. That's at least going to be added to Maxwell, and possibly Kepler too. Can also use fullscreen windowed.
Oh, cool.
>tfw no Fermi
Fullscreen windowed does have implications for performance though, even if slight. But I'll try how aero'd uncapped vs. VSync'd capped compare.

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

Re: NVIDIA Fast Sync

Post by Trip » 04 Jun 2016, 05:43

Sparky wrote:Nope. That's at least going to be added to Maxwell, and possibly Kepler too. Can also use fullscreen windowed.
It works on a 780 through inspector I bet if this latest driver works on fermi fast sync should work as well. You can always install nvidia inspector and see if the option is there and try it out.

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

Re: NVIDIA Fast Sync

Post by Sparky » 04 Jun 2016, 12:11

stirner wrote:
Sparky wrote: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.
So say I have 101Hz VSync'd @ 100fps capped. The latency difference to 100Hz FastSync'd @ 300fps won't be ~6.6ms as the framerates would determine, will it? Since effective framerate for the latter scenario still is 100fps, just that some of those 100 frames will contain slightly fresher data than the 100 frames in a capped scenario would.
The first one will have a latency at the start of each refresh cycle fluctuating between 0 and 9.9ms. The second one will have a value between 0 and 3.3ms. So on average it's only a 3.3ms reduction, but it will feel more like a 6.6ms reduction
Sparky wrote: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.
Yeah that makes more sense. I was referring your old results that I think didn't quite paint the same picture. Latency being lower because you cut the buffer is what I assumed, and so those results were counter-intuitive (and counter-empirical) to me back then (http://forums.blurbusters.com/viewtopic ... &start=270). But you did say it could have had to do with quirks of your setup.
IIRC that quirk only impacted the early vsync on tests. What happened was the sampling became synchronized with the refresh rate, so it only started sampling X ms after the refresh started instead of covering all possibilities. It was fixed before this post: http://forums.blurbusters.com/viewtopic ... 668#p15668

edit: Were you were talking about the refresh rate being 85.2hz instead of 85? There was some followup testing on a framerate cap just over refresh rate, latency started low, but over 30 seconds or so it slowly crept back up until it was identical to uncapped v-sync.

flood
Posts: 929
Joined: 21 Dec 2013, 01:25

Re: NVIDIA Fast Sync

Post by flood » 12 Jun 2016, 19:12

haven't really read this thread
it's interesting and definitely something that should have been done long long ago.

i'm still going to prefer playing without vsync and having tearing though, since not having tearing necessarily means that input latency is tied to the display scanout (i.e. middle of screen has almost half a refresh period latency, bottom has almost full refresh period latency)
plus tearing isn't really noticeable at 500fps :D

knypol
Posts: 76
Joined: 18 Aug 2016, 03:40

Re: NVIDIA Fast Sync

Post by knypol » 15 Dec 2016, 11:13

I noticed that Fast Sync cap fps by itself. I have monitor with 75Hz refresh and in BF1 with fast sync on I get exactly 150 fps. Hardware is able to push some more fps but its stuck at 150fps. I changed to lower resolution with 50Hz refresh and fps were caped at 200fps. Do I think right that Fast sync cap frames with multiplier of monitor refresh (in my case 2x75=150)? If my hardware was able to push 225 it would be capped at 225 (3X75)? I don't complain...with 150 fps I dont feel any input lag, no tearing and no stuttering but I'm just curious how this Fast sync works.

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

Re: NVIDIA Fast Sync

Post by RealNC » 15 Dec 2016, 13:35

Yes, it seems to cap to a multiple of the refresh in an attempt to produce less microstutter. I haven't figured out when it caps and when it doesn't though. It seems with some games, it doesn't cap. Well, either that, or RTSS is reporting wrong frame rates with fastsync... I don't know :-/
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.

Kirayamato
Posts: 23
Joined: 18 Dec 2013, 00:24

Re: NVIDIA Fast Sync

Post by Kirayamato » 31 Dec 2016, 06:03

hi currently have a 250 hz display and I play league of legends and it doesn't have a fps cap higher than 144 fps so either I can keep it uncapped which causes charactor movement going wacky which is a nogo or cap it at 144 fps or fastsync for 250 hz which would be lower input lag the smoothness doesn't matter since its league of legends

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

Re: NVIDIA Fast Sync

Post by RealNC » 31 Dec 2016, 09:36

Kirayamato wrote:hi currently have a 250 hz display and I play league of legends and it doesn't have a fps cap higher than 144 fps so either I can keep it uncapped which causes charactor movement going wacky which is a nogo or cap it at 144 fps or fastsync for 250 hz which would be lower input lag the smoothness doesn't matter since its league of legends
If your monitor has gsync or freesync, then use that. If not, use 144Hz, 144FPS cap, vsync on, be happy. 144Hz vsync input lag is so minor, it's not even worth mentioning for a game like LoL.
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: NVIDIA Fast Sync

Post by Chief Blur Buster » 22 Jan 2017, 12:22

Sparky wrote:I'll admit I was a bit disappointed, I was hoping it was a refresh synchronous framerate cap, so you can get low latency vsync AND smooth animation, provided you have consistent frametimes.
<AREA51>

Monitor engineering Idea:

I think Fast Sync could gain some clever additional tweaks even at the driver level.

In theory, you can use frame rendertime history to do a last-minute input read (mouse/keyboard), render the frame, and deliver it to the monitor just on time. Heck, you could even use the monitor's GSYNC flexibility to allow an approximately ~1ms jitter in frame rendertime completions. So being a few microseconds late for VSYNC doesn't matter -- the monitor's patience made possible by GSYNC capabilities just gave you a 1ms grace period for perfect VSYNC motion.

Then it'd, in theory, actually be mostly compatible with pre-existing strobe backlights, without noticeable flicker (jitter consistency is less important than stable average stroberate & perfectly stable strobe length). You'd gain your framerate == refreshrate == stroberate, with a combination of a modified "Fast Sync" + cleverly timed late input reads + GSYNC flexibility for slight jitter.

Currently, it's sorta possible to do this already by turning on GSYNC, then using an in-game framerate cap (e.g. fps_max), which provides you low-latency full-framerate motion, provided the game is designed properly (e.g. Executes input reads, renders & delivers frame to monitor as quickly as possible, with no pauses in between). But my suggestion is turning this into an official "forgiving fixed-framerate mode" with strobing capability. This might work well in GSYNC monitors that can be hacked to have ULMB enabled during GSYNC mode.

So in fact, this idea seems to be already sorta possible:
(1) Run one of those monitors that can be hacked in GSYNC mode
(2) Use an in-game framerate cap (this permits late input reads)
(3) If running games more complicated than Source engines, lower detail level a little bit so framerates don't fall below cap

Then you've got super fluid motion that's forgiving of late-rendertimes (VSYNC ON strobed without the input lag of VSYNC ON -- and without the big stutters of "missed VSYNC" situations).

Perhaps this should become an easy setting -- official monitor mode and graphics driver mode, for those who crave perfect motion fluidity (while having the minimum input lag compromises above else). Essentially a forgiving strobed VSYNC ON without the input lag compromises (only strobed lag, which can in theory be minimized to an average of only approx +1.25ms lag penalty during 240Hz strobing).

</AREA51>
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