Page 32 of 33

Re: G-Sync 101 w/Chart (WIP)

Posted: 01 Jun 2017, 11:25
by jorimt
kurtextrem wrote:I am not using any frame limiter. That is why I'm asking. I rarely reach > 150 fps anyway, but since I've turned on V-Sync (+ G-Sync) it hits 159 fps sometimes, but never goes over it.
Oh, I see what you're asking now. Yes, that's just a rounding error with the readout basically. 159/160Hz is the same thing in this instance.

If you're not reaching it the majority of the time, then you don't technically need an FPS limit. If you hit/exceed your max refresh rate more often than not, then yes, as RealNC already mentioned, limit the FPS with an in-game limiter when available, and RTSS when not.

RTSS does add 1 frame of delay, but that is way better than the 2+ frame delay experienced with uncapped G-SYNC + V-SYNC.

Re: G-Sync 101 w/Chart (WIP)

Posted: 01 Jun 2017, 11:50
by RealNC
@jorimt
jorimt wrote:RTSS does add 1 frame of delay, but that is way better than the 2+ frame delay experienced with uncapped G-SYNC + V-SYNC.
One thing to note here: RTSS "rounds up" to 1 frame of lag. It depends on how much time the frame took to render. For 60Hz, if the frame took 10ms to render, then RTSS adds 6.7ms of lag, not a whole frame. Obviously in high-framerate games like CS:GO and Overwatch, frames take so little time to render than RTSS ends up adding almost 1 frame of lag.

Another important thing is that RTSS does (in theory) not add any delay if the cap is not reached. However, if the cap is reached, input lag still doesn't get higher, because not having reached the cap means there's pre-rendered frames queued up. Reaching the cap keeps those extra queues empty (RTSS can not prevent the game from queuing frames if it's currently not limiting the frame rate.) In fact, RTSS reduces input lag in most games when the cap is reached.

This is a behavior I observed in most games (except games that focus on low latency, like CS:GO, Overwatch and Paladins, where I simply can't tell the difference without equipment.)

This is even true with "max pre-rendered frames" set to 1. The effect gets worse with higher values. To give an example, if I play Witcher 3 or Fallout 4 with a cap of 90FPS in RTSS, if the game runs at 89FPS or lower, there's more input lag than if it runs at 90FPS. It would appear that not reaching the cap means two frames of lag, reaching the cap means 0 to 1 frame of lag. Raising MPRF introduces additional frames of lag when the cap is not reached, and has no effect if the cap is reached.

In the case of Witcher 3, this is also true when using its own frame limiter (configurable through the game's ini file.)

It seems that frame rate limiting results in what many people claim MPRF 0 did in very old driver versions where (according to those people) it removed a whole frame of lag compared to MPRF 1.

This is easily testable by raising MPRF to maximum in profile inspector and making sure the game is not able to reach maximum refresh ("Ultra" details usually help here.) Then, cap FPS to 2 or 3 FPS below what the game currently renders at. All that input lag goes away. Again, this is even true with MPRF 1.

So in fact, capping to a lower value than you normally would, even with RTSS, can help reduce input lag. If your game usually runs at 90FPS and you cap to 142, you're getting some input lag. Capping to 88 instead reduces input lag.

Re: G-Sync 101 w/Chart (WIP)

Posted: 01 Jun 2017, 15:15
by jorimt
@RealNC

Yup, aware of the "rounds up" factor; in my testing, at 144Hz, for instance, RTSS only added around 4-5ms (as opposed to a full 6.9 frame) on average for some of the reasons you laid out.

My in-progress article makes it clear that RTSS only adds "up" to 1 frame of delay, by the way.

Some of your other points I can't speak to, as I haven't messed around with RTSS enough myself, at least at that level, to know one way or another.

Short of basic comparative input latency tests (which my article will contain), FPS limiters are pretty much an endless subject in and of themselves.

Re: G-Sync 101 w/Chart (WIP)

Posted: 02 Jun 2017, 00:25
by kurtextrem
Great insights, thank you guys.

Re: G-Sync 101 w/Chart (WIP)

Posted: 06 Jun 2017, 23:09
by drmcninja
kurtextrem wrote:My G-Sync isn't working if I have vsync on + gsync, but fps never goes over 159 fps, or is it?
Does turning on G-Sync do something to nullify the V-Sync input lag? I don't see how else G-Sync ON, V-Sync ON would have less lag than just V-Sync ON, with both set to -2 fps below Refresh Rate.

Re: G-Sync 101 w/Chart (WIP)

Posted: 06 Jun 2017, 23:31
by Sparky
drmcninja wrote:
kurtextrem wrote:My G-Sync isn't working if I have vsync on + gsync, but fps never goes over 159 fps, or is it?
Does turning on G-Sync do something to nullify the V-Sync input lag? I don't see how else G-Sync ON, V-Sync ON would have less lag than just V-Sync ON, with both set to -2 fps below Refresh Rate.
With g-sync the start of the refresh cycle stays synchronized with frame completion, so on average it will be half a frame lower latency than vsync without g-sync. Assuming both are capped below the refresh rate.

Re: G-Sync 101 w/Chart (WIP)

Posted: 12 Jun 2017, 15:23
by drmcninja
RealNC wrote:@jorimt
jorimt wrote:RTSS does add 1 frame of delay, but that is way better than the 2+ frame delay experienced with uncapped G-SYNC + V-SYNC.
One thing to note here: RTSS "rounds up" to 1 frame of lag. It depends on how much time the frame took to render. For 60Hz, if the frame took 10ms to render, then RTSS adds 6.7ms of lag, not a whole frame. Obviously in high-framerate games like CS:GO and Overwatch, frames take so little time to render than RTSS ends up adding almost 1 frame of lag.

Another important thing is that RTSS does (in theory) not add any delay if the cap is not reached. However, if the cap is reached, input lag still doesn't get higher, because not having reached the cap means there's pre-rendered frames queued up. Reaching the cap keeps those extra queues empty (RTSS can not prevent the game from queuing frames if it's currently not limiting the frame rate.) In fact, RTSS reduces input lag in most games when the cap is reached.

This is a behavior I observed in most games (except games that focus on low latency, like CS:GO, Overwatch and Paladins, where I simply can't tell the difference without equipment.)

This is even true with "max pre-rendered frames" set to 1. The effect gets worse with higher values. To give an example, if I play Witcher 3 or Fallout 4 with a cap of 90FPS in RTSS, if the game runs at 89FPS or lower, there's more input lag than if it runs at 90FPS. It would appear that not reaching the cap means two frames of lag, reaching the cap means 0 to 1 frame of lag. Raising MPRF introduces additional frames of lag when the cap is not reached, and has no effect if the cap is reached.

In the case of Witcher 3, this is also true when using its own frame limiter (configurable through the game's ini file.)

It seems that frame rate limiting results in what many people claim MPRF 0 did in very old driver versions where (according to those people) it removed a whole frame of lag compared to MPRF 1.

This is easily testable by raising MPRF to maximum in profile inspector and making sure the game is not able to reach maximum refresh ("Ultra" details usually help here.) Then, cap FPS to 2 or 3 FPS below what the game currently renders at. All that input lag goes away. Again, this is even true with MPRF 1.

So in fact, capping to a lower value than you normally would, even with RTSS, can help reduce input lag. If your game usually runs at 90FPS and you cap to 142, you're getting some input lag. Capping to 88 instead reduces input lag.
So what would the input lag be like with:

MPRF = 2
In-game FPS limiter set to 119 (V-Sync @ 120Hz)
And game constantly hitting the limit and not dropping below

vs.

MPRF = 1
In-game FPS limiter set to 119 (V-Sync @ 120Hz)
And game constantly hitting the limit and not dropping below

Would there be any benefit to using MPRF at a higher value? Maybe even smoother motion without that saw pattern in input lag?

Re: G-Sync 101 w/Chart (WIP)

Posted: 12 Jun 2017, 16:56
by Sparky
drmcninja wrote: So what would the input lag be like with:

MPRF = 2
In-game FPS limiter set to 119 (V-Sync @ 120Hz)
And game constantly hitting the limit and not dropping below

vs.

MPRF = 1
In-game FPS limiter set to 119 (V-Sync @ 120Hz)
And game constantly hitting the limit and not dropping below

Would there be any benefit to using MPRF at a higher value? Maybe even smoother motion without that saw pattern in input lag?
There will be no difference in that situation, because the in game framerate cap will keep the queue from filling.

Re: G-Sync 101 w/Chart (WIP)

Posted: 12 Jun 2017, 17:21
by kingbenjie
Hey there jorimnt, I'm back with a little troubleshooting that maybe you can help me with.

The Issue:

Recently when I have any application open on my non-gaming monitor my gaming monitor FPS drops by like 25-30%. So like for example I'll be playing Overwatch at a constant 162 FPS (still using your recommended settings), but as soon as I open any application on my second monitor and click back to Overwatch my FPS drops by a lot and the performance drop is evident. Now, I can have multiple applications running with no problems BUT the problem appears only when any of those given applications are actually put in view on the second monitor.

I didn't use to have this problem. I don't know what is causing it. Got any idea of what it might be?

Thanks!

Re: G-Sync 101 w/Chart (WIP)

Posted: 12 Jun 2017, 22:34
by jorimt
@kingbenjie,

I'm guessing your secondary monitor has a lower/different refresh rate than your primary G-SYNC monitor. If so, mixed refresh dual monitor setups do not play nicely with G-SYNC, and cause that very problem.

I'm afraid the issue is more on Microsoft's end than it is Nvidia's, and I'm not aware of anything that can fix it other than setting both monitor's to the same refresh rate. My dual monitor setup can have similar issues.