Blur Busters Forums

Is there any reason to disable fullscreen optimizations? It's essentially just to make sure triple buffering vsync isn't applied correct?

I'm still trying to make sense of Chris's results before writing a summary to share in other forums, and two things are bugging me:

1. In the "not GPU bound" scenario, with G-Sync ON, V-Sync ON and an FPS cap below the refresh rate, he tested NULL with a different in-game cap than in his previous tests.

I wish that he performed all tests using the same in-game cap of 139, instead of 130, so we could compare all input latency results. A higher framerate, even if by just 9 frames, will incur in higher input latency no matter what.

2. In the "GPU bound" scenario, again with G-Sync ON and V-Sync ON, he only tested NULL without an FPS cap below the refresh rate.

Games with high GPU utilization are the most common scenario for most non-competitive players, so it'd be helpful to see the results of NULL with G-Sync ON, V-Sync ON and the FPS capped at a value below the display's maximum refresh rate.

I'll try to reach out to him to clarify those questions.

jorimt wrote:

disq wrote:What about games that don't have Vsync - ON as an option but only "Double Buffered", "Triple Buffered", "Adaptive", "Adaptive (1/2 Rate)" like the case on Apex Legends. Which one should we pick?

G-SYNC functions on a double buffer, so select in game "Double Buffered" or force V-SYNC to "On" in the NVCP for those instances.

Just to confirm: if we force enable V-Sync on NVCP, we should disable all forms of buffering in-game?

RDR2 has the option to enable or disable triple buffering, not sure what to do with it.

tygeezy wrote:Is there any reason to disable fullscreen optimizations? It's essentially just to make sure triple buffering vsync isn't applied correct?

Read the last entry of my Closing FAQ.

EeK wrote:1. In the "not GPU bound" scenario, with G-Sync ON, V-Sync ON and an FPS cap below the refresh rate, he tested NULL with a different in-game cap than in his previous tests.

I wish that he performed all tests using the same in-game cap of 139, instead of 130, so we could compare all input latency results. A higher framerate, even if by just 9 frames, will incur in higher input latency no matter what.

2. In the "GPU bound" scenario, again with G-Sync ON and V-Sync ON, he only tested NULL without an FPS cap below the refresh rate.

Games with high GPU utilization are the most common scenario for most non-competitive players, so it'd be helpful to see the results of NULL with G-Sync ON, V-Sync ON and the FPS capped at a value below the display's maximum refresh rate.

I don't believe there would be a point to testing such scenarios. Any setting that is dedicated to reducing the pre-rendered frames queue only takes effect with uncapped framerates (above or below the refresh rate, G-SYNC/V-SYNC or no sync), and/or only in GPU-bound scenarios.

If your FPS is limited by an FPS cap, the pre-rendered frames queue shouldn't apply, thus the settings to reduce it don't either. More on this in entries #6 and #8 of my Closing FAQ.

Also, while you've probably already seen it, here is my follow-up post for the video he released today:
viewtopic.php?f=5&t=5903&start=30#p44825

EeK wrote:Just to confirm: if we force enable V-Sync on NVCP, we should disable all forms of buffering in-game?

RDR2 has the option to enable or disable triple buffering, not sure what to do with it.

Yes, pick: in-game or NVCP V-SYNC, not both.

As for triple buffer V-SYNC/options, again, it's worthless with G-SYNC, as G-SYNC runs on a double buffer.

And even if triple buffer did do anything with G-SYNC, it would simply add a third buffer (and disrupt frame pacing), and thus, at "best," add 1 more frame of input lag (you can get close to this with G-SYNC + Fast Sync, which also auto-caps the FPS, but you get recurring stutter due to Fast Sync, a triple buffer solution, still being active at/near the cap).

Kamil950 wrote: Maybe it could be good idea to add what you wrote in this link below (on guru3D forums) to G-Sync FAQ on BlurBusters?

https://forums.guru3d.com/threads/the-t ... st-5692121

If somebody would read only G-Sync FAQ on BlurBusters he/she would not know that he/she could has shorter stutters (but with a tear) which seems (at least to me) better compromise than longer stutter (but without tear).

That's a tricky subject, because frametime spikes "suck" no matter what configuration you have. That, and no input updates are reflected during the frametime spike (nor can you technically control anything in that time span), so the increase in responsiveness between the two scenarios is typically extremely minimal where frametime spikes are frequent.

Also, G-SYNC + V-SYNC is only worse than G-SYNC + V-SYNC "Off" in this respect sometimes; it depends on the progression percentage of the given scanout cycle when your input and/or the scene change is registered during a frametime spike (think of it as rolling dice).

Often (barring the occasional non-gameplay scenario, where a menu transition may cause the FPS to go from exactly 0 to x FPS or visa-versa), there is no difference between the two at all.

As for laying all this out in an FAQ entry, that might confuse the message where "optimal" settings are concerned...

If you read entry #2 of my Closing FAQ, you may see that if I all of the sudden I then say, "but don't use V-SYNC with G-SYNC, because of this thing that shouldn't happen in a good engine in the first place, and it's only sometimes worse...", then it's going to complicate things for readers that have yet to comprehend some of the more nuanced aspects of this subject.

My optimal listed G-SYNC settings are just that, "optimal," so if the user wants to disable V-SYNC with G-SYNC, even knowing the possible benefits of using V-SYNC over V-SYNC "Off" with G-SYNC, they are free to do so.

That said, I'll consider it (and have already toyed with the idea on addressing it); I periodically update the FAQ when I find something worth saying.

disq wrote:Thanks for the info

Sorry, missed this previously; you're welcome

jorimt wrote:I don't believe there would be a point to testing such scenarios. Any setting that is dedicated to reducing the pre-rendered frames queue only takes effect with uncapped framerates (above or below the refresh rate, G-SYNC/V-SYNC or no sync), and/or only in GPU-bound scenarios.

If your FPS is limited by an FPS cap, the pre-rendered frames queue shouldn't apply, thus the settings to reduce it don't either. More on this in entries #6 and #8 of my Closing FAQ.

Well, he did test NULL with an FPS cap, but only in the "not GPU bound" scenario, as I mentioned.

If you check the results, both the maximum and minimum input lag are increased with a lower framerate, as expected (even though the average remains about the same). I just wish that, like in his previous tests, he had capped the FPS at 139, for the sake of consistency. There's a difference of half a milisecond in frametimes between 139 FPS (7.19ms) and 130 FPS (7.69ms), I'm curious to see if that would result in an even lower input latency, or if it would be impossible to measure.

In the end, NULL is only recommended if you don't cap the framerate at all? If you do choose to use an FPS limiter, NULL should be disabled in all scenarios?

jorimt wrote: Yes, pick: in-game or NVCP V-SYNC, not both.

I should've been more clear. When I said "buffering", I only meant double buffering and triple buffering. V-Sync should not be enabled both in-game and on NVCP.

I only asked because I had never seen that setting in any games until RDR2 (where it's separate from V-Sync), and another user also mentioned Apex Legends as having the option of a double buffer.

jorimt wrote:As for triple buffer V-SYNC/options, again, it's worthless with G-SYNC, as G-SYNC runs on a double buffer.

Okay, so if the game only has an option for triple buffering, like RDR2, we should disable it. But if it has a double buffer setting, that should be enabled in-game on top of V-Sync?

One last question regarding fullscreen optimizations, and your following quote (from the Closing FAQ):

So while it’s usually safe to disable this option for most games, it should first be verified that G-SYNC is functioning (either via the “G-SYNC indicator” setting in NVCP, or built-in refresh rate meter on supported monitors) when the “Disable fullscreen optimizations” checkbox is “checked” per game exe.

My TV doesn't have a built-in refresh rate meter, so that option is out. What is the "G-SYNC indicator" setting that you mentioned, though? Would the option for G-Sync disappear from "Monitor Technology" in each individual program setting, if you disable fullscreen optimizations for the executables of problematic games?

EeK wrote:If you check the results, both the maximum and minimum input lag are increased with a lower framerate, as expected (even though the average remains about the same). I just wish that, like in his previous tests, he had capped the FPS at 139, for the sake of consistency. There's a difference of half a milisecond in frametimes between 139 FPS (7.19ms) and 130 FPS (7.69ms), I'm curious to see if that would result in an even lower input latency, or if it would be impossible to measure.

Those differences look within margin of error to me. I think he only does 20 samples per test (I did 40 per in my tests), so his variances are going to be slightly greater between identical or similar scenarios.

As for the measurable difference between 139 FPS and 130 FPS where input lag caused by the actual raw average frametime difference between the two is concerned, there isn't an appreciable one, no.

EeK wrote:In the end, NULL is only recommended if you don't cap the framerate at all? If you do choose to use an FPS limiter, NULL should be disabled in all scenarios?

Once your system's framerate can be maintained above you're maximum refresh rate, and you've prevented both V-SYNC and GPU input lag using an FPS limiter, there's not much more reduction you can expect to get on the system/display side, and where there is, we're talking severely diminishing returns; a blink vs. a bat of an eyelash, basically. Some people can't even tell the difference between uncapped G-SYNC + V-SYNC vs. capped G-SYNC + V-SYNC @144Hz in actual practice, for instance.

And I think I covered that NULL question pretty thoroughly in a previous post:

Regarding Low Latency Mode "Ultra" vs. "On" when used in conjunction with G-SYNC + V-SYNC + -3 minimum FPS limit, I'd currently recommend "On" for two reasons:

1. "On" should have the same effect as "Ultra" in compatible games (that don't already have a MPRF queue of "1") in reducing the pre-rendered frames queue and input lag by up to 1 frame whenever your system's framerate drops below your set FPS limit vs. "Off."

2. Since "Ultra" non-optionally auto-caps the FPS at lower values than you can manually set with an FPS limiter, for the direct purposes of point "1" above, you'd have to set your FPS limiter below that when using "Ultra" to prevent it from being the framerate's limiting factor, and allow the in-game (or RTSS) limiter to take effect. At 144Hz, you would need to cap a couple frames below 138, which isn't a big deal, but at 240Hz, "Ultra" will auto-cap the FPS to 224 FPS, which I find a little excessive, so "On" which doesn't auto-cap, but should still reduce the pre-rendered frames queue by the same amount as "Ultra" in GPU-bound situations (within the G-SYNC range) is more suited to such a setup.

--------

EeK wrote:I should've been more clear. When I said "buffering", I only meant double buffering and triple buffering. V-Sync should not be enabled both in-game and on NVCP.

I only asked because I had never seen that setting in any games until RDR2 (where it's separate from V-Sync), and another user also mentioned Apex Legends as having the option of a double buffer.

Yeah, I wasn't targeting your comment specifically, there. I'm just trying to spell things out as much as possible, as people tend to get paranoid when discussing this (or with any finicky technical subject like it).

Triple buffer is the only option that is technically "separate" of (double buffer) V-SYNC in the games that have that option. That is, you can have (double buffer) V-SYNC enabled in-game without having the triple buffer option enabled at the same time.

These triple buffer options aren't "true" triple buffer, and instead simply tack a third buffer onto the already enabled double buffer option, as to prevent the lock to half refresh when the framerate falls below the refresh rate when using standalone V-SYNC.

More details in the last couple paragraphs of a page in my article here:
https://www.blurbusters.com/gsync/gsync ... ettings/4/

If you see "Double Buffer" as an option in a game, that's just another term for standard V-SYNC, whereas "Triple buffer" (in those instances where that option is available) is for enabling on top of the base V-SYNC/"Double Buffer" option (it usually won't work without the double buffer/V-SYNC option enabled first, where the options are separate, that is).

EeK wrote:Okay, so if the game only has an option for triple buffering, like RDR2, we should disable it. But if it has a double buffer setting, that should be enabled in-game on top of V-Sync?

Yes on the triple buffer option, no on the double buffer option, as that is just another term for standard V-SYNC (you'd be enabling it twice).

EeK wrote:My TV doesn't have a built-in refresh rate meter, so that option is out. What is the "G-SYNC indicator" setting that you mentioned, though? Would the option for G-Sync disappear from "Monitor Technology" in each individual program setting, if you disable fullscreen optimizations for the executables of problematic games?

There are limitations and exceptions to this, but generally, if you enable the above option, and you're not seeing that indicator in the game, G-SYNC isn't currently active.

@jorimt

If my monitor's native is 1440p w/ gsync on, what NVCP settings do you recommend for CoD:MW? The in-game fps monitor doesn't work for me as others have mentioned.

If I am running higher than 1080p, does that mean it will put "strain" on my gpu for all games ran at 1440p?

Right now I am using: 1440p in game, RTSS set to 160 (165hz monitor), NVCP: gsync on, vsync on, NULL set to ON instead of Ultra. Vsync off in game. Do you recommend these settings or anything different? Thank you!

edit: reading another member's post is giving me conflicting answers. In my specific case, null should be on or off?

@jorimt, thank you very much for taking the time to answer all of my questions. You've been incredibly helpful and patient, which I really appreciate. I've learned a lot from your articles and, now, even more from your posts.



P.S.: I'll be trying out that G-SYNC Indicator option! Had never noticed it until you pointed it out.

a22o2 wrote:If I am running higher than 1080p, does that mean it will put "strain" on my gpu for all games ran at 1440p?

A higher resolution will indeed always put more strain on your GPU. Use RTSS to monitor your GPU usage percentage.

Ideally, you want it to be below 99% usage for input lag purposes, but preventing V-SYNC input lag with an FPS limit below the refresh rate with G-SYNC (as you already have set), will net you the most input lag reduction (typically 2 or 3, but sometimes up to 6 frames in extreme instances) out of anything else you can do on the system/display side (Low Latency Mode, both "On" and "Ultra" will, at best, usually net you an additional 1 frame of input lag reduction in uncapped/GPU-bound situations).

a22o2 wrote:Right now I am using: 1440p in game, RTSS set to 160 (165hz monitor), NVCP: gsync on, vsync on, NULL set to ON instead of Ultra. Vsync off in game. Do you recommend these settings or anything different? Thank you!

edit: reading another member's post is giving me conflicting answers. In my specific case, null should be on or off?

Sound right to me, including NULL "On"...except for this game; it runs on DX12, and DX12/Vulkan currently handle the pre-rendered frames queue at the engine level, and thus don't support external setting's manipulation of the queue size.

No harm in leaving it on though, as it won't have an affect anyway in this case.