Page 29 of 65

Re: Blur Buster's G-SYNC 101 Series Discussion

Posted: 24 Sep 2017, 08:18
by knypol
To clarify if I understand right: if i have 144Hz monitor with NVCP Vsync ON should I cap in-game to 144fps to reduce input lag? Some in-game limiters are not to precise...vary from 142-147.In such case is it better to limit with RTSS (143.999)?

Re: Blur Buster's G-SYNC 101 Series Discussion

Posted: 24 Sep 2017, 09:19
by RealNC
knypol wrote:To clarify if I understand right: if i have 144Hz monitor with NVCP Vsync ON should I cap in-game to 144fps to reduce input lag? Some in-game limiters are not to precise...vary from 142-147.In such case is it better to limit with RTSS (143.999)?
With g-sync? No. You should cap to 141FPS.

Without g-sync, you need RTSS with a cap that's 0.01 lower than your real refresh rate, as described here:

http://www.blurbusters.com/howto-low-lag-vsync-on/

Re: Blur Buster's G-SYNC 101 Series Discussion

Posted: 24 Sep 2017, 10:18
by jorimt
kurtextrem wrote:Sorry, I think I've posted this question at some point, but this new (?) research makes me feel a little uncertain.
You guys are talking about added input lag when NOT using RTSS to cap when having G-Sync on. But G-Sync only has added input lag if fps > refresh rate, right?
We're talking system-induced latency at this point vs. sync-induced latency. They are two separate sections of the input latency chain (first half of "Computer" section vs. last half of "Computer" section to "Display" section, basically):

Image

To make it simple, G-SYNC within the refresh rate is still the lowest lag you're going to get from a syncing method between the "Computer" and "Display" level, but if the framerate limiter is the framerate's limiting factor at all times, then you'd have even lower lag, as you're effectively eliminating the process of pre-rendered frames at the "Computer" CPU/engine-level.

We can take this further and lower net lag by using a mouse and keyboard with less latency at the "Input Device" level, and so forth; it's all part of one big, complicated input latency chain, beginning with the human response element (reaction time).

My G-SYNC 101 series (and recommended settings) only covers part of it.

Re: Blur Buster's G-SYNC 101 Series Discussion

Posted: 26 Sep 2017, 02:06
by Vleeswolf
Hi jorimt,

Would it be interesting to see how some OpenGL games, like Doom (2016) and No Man's Sky behave wrt. input lag? With these games I feel there is hardly any difference in lag between limiting frame rates 3 FPS below the max. refresh rate (100Hz in my case), or letting frame rate hit the max refresh. At least there is no difference I can observe easily ;-)

Vleeswolf

Re: Blur Buster's G-SYNC 101 Series Discussion

Posted: 26 Sep 2017, 09:36
by jorimt
First off, are you running with G-SYNC + V-SYNC "Off" + -3 FPS limit or G-SYNC + V-SYNC "On" + -3 fps limit?

Re: Blur Buster's G-SYNC 101 Series Discussion

Posted: 26 Sep 2017, 12:44
by Vleeswolf
jorimt wrote:First off, are you running with G-SYNC + V-SYNC "Off" + -3 FPS limit or G-SYNC + V-SYNC "On" + -3 fps limit?
The latter, tried both in-game VSYNC or with NVCPL. In case of Doom I used RTSS to limit the frame rate, to no obvious effect. In NMS I use its internal rate limiter.

Re: Blur Buster's G-SYNC 101 Series Discussion

Posted: 26 Sep 2017, 14:15
by jorimt
Whether you are playing a game with OpenGL or DirectX, the base mechanics of frame delay don't change, especially in this specific scenario.

So either your framerate isn't reaching or exceeding your max refresh rate enough to cause this delay (this is likely in No Man's Sky, depending on the settings, less likely in Doom; easier to run), or congrats, you're one of the "lucky" ones who can't differentiate the base X ms of delay from the Y ms delay added by syncing methods.

One way to tell how sensitive you are to added delay is to try the program in this thread:
viewtopic.php?f=10&t=1134

That said, I still recommend setting games -2 to -3 FPS below your max refresh rate when using G-SYNC, because even though you may not be able to perceive the reduction in latency, you'll keep G-SYNC in its range at all times, preventing both the delay and the stutter that can be caused when it bounces in and out of its range when hitting the max refresh rate.

Re: Blur Buster's G-SYNC 101 Series Discussion

Posted: 26 Sep 2017, 15:31
by Vleeswolf
Nice test tools. It appears I can differentiate pretty well up to about the base 20 ms scenario ;-)

I notice the effect of frame limiting a lot more for DirectX games, ie. not doing the -3 FPS resulting in floaty cursors etc. Wouldn't OpenGL handle frame queuing differently, for instance, having no swap chain normally?

Re: Blur Buster's G-SYNC 101 Series Discussion

Posted: 26 Sep 2017, 17:19
by jorimt
If you're using G-SYNC + V-SYNC "On" with no FPS limiter, and your framerate is exceeding your refresh rate at all times, then OpenGL or no, with double buffer V-SYNC active, the buffers are going to over-queue...unless those two games are engaging a form of "true" triple buffer V-SYNC instead, which basically acts like Fast Sync above the refresh rate.

While that scenario wouldn't be as low latency as G-SYNC with an FPS limit below the refresh rate, it would be much lower latency than double buffer V-SYNC in this instance.

I own both of those games, but haven't gotten around to testing either, so I can't confirm if that's the case though.

Re: Blur Buster's G-SYNC 101 Series Discussion

Posted: 01 Oct 2017, 13:22
by efflexthy
For games like PUBG where framerates are unstable and fluctuate VERY often(e.g. Quite often fps drops to 60-80 when it sits at anywhere between 120-160 fps on other areas) what would be the ideal setting to use for lowest input lag possible? I'm currently using a 144 hz monitor.

As a followup, do you enable/disable triple buffering in the NVCP for when you use G-sync + V-sync ON with 141 fps cap? It is mentioned to turn off triple buffering in-game but not specified in NVCP. Does it even matter?