Blur Busters Forums

disq wrote:We are lucky to have you on this community, jorimt. Thank you for all the help & information you provide us with.

Thanks @disq, happy to assist

Using Apex again as example (as this is the game i play the most at the moment) i switched to the in-game FPS limiter (either via autoexec or launch options) and i noticed that if i set V-Sync in-game to Double Buffered (it only offers "Double Buffered", "Triple Buffered", "Adaptive", "Adaptive (1/2 Rate)") it doesn't honor the limit i set, e.g i set it to 138 and it goes to 165, don't even know why that specific number. The same goes for "Triple Buffered" and the other two go to 250+.

This only happens in Fullscreen, if i set it to windowed it honors the cap i set.

I assume that in such cases as this we're forced to use V-Sync from NVCP, correct? Unless i'm missing something

I realized that if I activate vsync in the NVCP and I do not activate it in a game in this case Fortnite, it is not really working, I did the test on my brother's laptop that has a 1050 graph, if I activate vsync in the control panel of nvidea and in the game is deactivated the screen tearing stripes appear, but when I turn it on they disappear which means that if I do not activate it in the game directly it will not be activated and tearing will continue to appear.

Which can mean that some games do require that it be activated directly from this one so that it works vsync, so that it works as it should gsync + vsync, is what I think correct me if I am wrong please.

@disq, @Raiden, regarding this, I've had this information available in my article since 2017 (especially note the last paragraph in bold):
https://www.blurbusters.com/gsync/gsync ... ttings/14/

Nvidia Control Panel V-SYNC vs. In-game V-SYNC

While NVCP V-SYNC has no input lag reduction over in-game V-SYNC, and when used with G-SYNC + FPS limit, it will never engage, some in-game V-SYNC solutions may introduce their own frame buffer or frame pacing behaviors, enable triple buffer V-SYNC automatically (not optimal for the native double buffer of G-SYNC), or simply not function at all, and, thus, NVCP V-SYNC is the safest bet.

There are rare occasions, however, where V-SYNC will only function with the in-game option enabled, so if tearing or other anomalous behavior is observed with NVCP V-SYNC (or visa-versa), each solution should be tried until said behavior is resolved.

99% of the time, either in-game or NVCP V-SYNC is fine to use with G-SYNC, but since this is a per-game issue, user experimentation is required for these instances, unfortunately, with no one "right" answer for such occurrences.

Thanks for your response always very fast, in my case with my computer that has a 1080ti I do not get screen tearing, but I thought it was necessary that V-SYNC worked together with G-SYNC so I decided to try on my brother's laptop and I realize this, that if V-SYNC is not active in the game, screen tearing come out even if it was activated in the NVCP, but in my case as they do not come out even if it is deactivated in the game I suppose it is enough to activate it in the NVCP.

Although thinking it well it may be because my brother's laptop does not have G-SYNC, so V-SYNC must be activated in the game by obligation, since your article mentions that G-SYNC adds its own frame buffer and I have a monitor that supports it, so it is not necessary to activate it in the game in my case.

@Raiđen, I don't know enough about your brother's computer to say one way or another why V-SYNC is only working in Fornite when you use the in-game solution.

Also, even with a G-SYNC display, for no tearing 100% of the time, you want to use G-SYNC + V-SYNC (in-game or NVCP) + -3 FPS limit.

jorimt, once again, thank you for the information and sorry for missing that

I will then keep using RTSS as that allows me to use V-Sync on in-game and honors my FPS limit

disq wrote:jorimt, once again, thank you for the information and sorry for missing that

I will then keep using RTSS as that allows me to use V-Sync on in-game and honors my FPS limit

Sorry @disq, I didn't have the time to test this myself yesterday, thus the generic (but still valid) initial response.

I've just tested it now, and you're right, the in-game limiter in Apex Legends appears to not work with (any form of) in-game V-SYNC enabled, at least with G-SYNC (didn't test without). It does work with V-SYNC entirely disabled or NVCP V-SYNC enabled, however (obviously RTSS works in any of those configuration).

I'm not sure why it's doing this, but it just goes to show that V-SYNC implementation can vary from game to game. Though again, it's affect on G-SYNC is usually going to be minimal to non-existent whether you use in-game or NVCP V-SYNC. This is just one of those rare, 1% instances where it (indirectly won't keep G-SYNC in it's range if you use in-game limiter + in-game V-SYNC) does.

I'd also add that this actually further validates my existing recommendation to use NVCP V-SYNC with G-SYNC to avoid these rare occurrences.

For thoroughness sake though, I'm not saying you shouldn't use in-game V-SYNC + RTSS (either that or the in-game limiter + in-game/NVCP V-SYNC is fine), I'm just saying for those that wouldn't have spotted or troubleshooted this, they would have unknowingly been playing outside the G-SYNC range when/if their framerate exceeded the refresh rate, thus the reason for my default optimal settings being more generic than specific.

Vleeswolf wrote:Since the addition of the NULL, the Nvidia driver frame rate limiter appears also low latency. The driver api documentation** since then has a new field as well, PS_FRAMERATE_LIMITER_LOW_LATENCY_AUTO , which replaces a flag that Nvidia profile inspector already set by default. If you set the frame rate limit in Nvidia profile inspector, this seems to work fine. I’m seeing the same latency numbers (using PresentMon) as RTSS in most of my games. If you disable the new low latency profile flag, latency bumps up to 2-3 frames as before NULL, depending on pre-render queue settings.

** https://docs.nvidia.com/gameworks/conte ... d72661a71f

I'm revisiting this (just an anecdote), because I entirely forgot that I tested something similar back when I released the article originally:
viewtopic.php?f=5&t=3441#p26810

it seems like NULL is exhibiting equivalent behavior with the new flag, and thus, from the high speed data currently available, effectively appears to be between the original NVI limiter and the RTSS limiter where input lag levels are concerned.