Re: Driver 441.08: Ultra-Low Latency Now with G-SYNC Support
Posted: 04 Nov 2019, 20:13
What is the verdict on NULL Ultra in high-FPS, entirely CPU-driven games (e.g. CSGO)? Enable or disable?
Who you gonna call? The Blur Busters! For Everything Better Than 60Hz™
https://forums.blurbusters.com/
Looking forward to that video. Chris confirmed on Twitter that NULL "isn't a magic FPS limiter" (in his own words). He also recommended to have VSync enabled in-game, instead of at the driver level, because developers may "decide to trigger other optimizations in the engine when you enable VSync inside the game" (again, his words).jorimt wrote:Not with that game, but I have with several others. As I've (repeatedly) stated via previous comments in this thread though, until more testing is done, I can't guarantee what that combo is doing, and I can't currently recommend it over an FPS limiter.
Batle(non)sense is reportedly due to release a test video on it soon.
I hadn't, either, until very recently. Although I'm convinced that what caused my saves to disappear was switching the ownership back and forth, and not simply taking ownership of the WindowsApps folder in the first place.jorimt wrote:I can't say I've experienced anything close to that after taking control over the WindowsApps folder for game exe access, but, yes, feel free to avoid the method if you're not comfortable with it.
Awesome to see you here, too, tygeezy! Be sure to check out the PCGamingWiki for potential fixes and workarounds for all games. And if you're planning on playing The Outer Worlds, I came up with some INI file edits to remove most of the HUD elements in that game, without affecting gameplay. Let me know via DM if you're interested, and I can link them to you.tygeezy wrote:awesome to see you here too Eek. I'm patiently awaiting battlenonsense video. It would be great to just setup gsync + vsync + ultra low latency and forget it.
It would be nice to do less dicking around trying to hover under 97 % gpu usage as well as below the refresh rate ceiling to optimize input lag. I'm going to want to have less static elements on my screen now that i'm going to be gaming on the c9 oled.
Yup, I said something similar about NVCP vs. in-game V-SYNC in my article originally as well:EeK wrote:He also recommended to have VSync enabled in-game, instead of at the driver level, because developers may "decide to trigger other optimizations in the engine when you enable VSync inside the game" (again, his words).
--------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.
Again, DWM composition (which is the very thing that forces its own form of triple buffer V-SYNC in traditional borderless or windowed modes) is not engaged when the game window is focused/active with the hybrid borderless/exclusive fullscreen mode (only with actual borderless or windowed mode), so, G-SYNC or no G-SYNC, while it's not impossible, that shouldn't be the case if you're using the in-game "Fullscreen" option, even with fullscreen optimizations enabled for the exe.EeK wrote:I haven't experimented with other titles, aside from The Outer Worlds, but I forgot that I'm playing the Microsoft Store version of the game, which, due to its fullscreen optimizations and "fake" exclusive fullscreen mode, probably has triple buffering applied to it by default, since Windows forces the use of DWM.
That may explain the odd frame limiting behavior. Or not. I honestly have no idea, and this new implementation of exclusive fullscreen still is a mystery to me.
But Chris made it sound like those optimizations are good, while, from your article, it's pretty clear that they're bad. Aside from tearing, what other "anomalous behavior" should we be looking out for when testing in-game VSync vs. NVCP VSync?jorimt wrote:Yup, I said something similar about NVCP vs. in-game V-SYNC in my article originally as well:
https://www.blurbusters.com/gsync/gsync ... ttings/14/
Yep, it was a tear-fest. I may have disabled fullscreen optimizations for the game's executable prior to reverting ownership of the WindowsApps folder, but that shouldn't make any difference, as you mentioned. I thought that this could be related to the "magic" FPS limiting of NULL, but I was clearly incorrect.jorimt wrote:If you want to check Outer Worlds for this specifically, disable G-SYNC and force V-SYNC off in the NVCP; you should see tearing in this scenario.
I interpreted it as him inferring that the "optimizations" may interfer, or basically, increased the possible variables when testing (and I quote):EeK wrote:But Chris made it sound like those optimizations are good, while, from your article, it's pretty clear that they're bad.
But in further comments there, yes, it appears it's of his opinion that in-game V-SYNC is generally fine to pair with G-SYNC.the v-sync option in-game can also trigger other optimizations in the game-engine (which is why when comparing/testing end-to-end delay in different games nvidia recommends to use the nvcpl v-sync option).
Possibly increased stutter (micro or otherwise) and/or slightly more input lag due to possible extra buffer/flip queue behavior using the in-game solution. But, granted, this would be extremely rare.EeK wrote:Aside from tearing, what other "anomalous behavior" should we be looking out for when testing in-game VSync vs. NVCP VSync?
It's simply an example of a safe limit.wist7 wrote:V-sync on in nvcp, off in-game, rtss fps cap at 141 and now I'm confused, why he cap it at 138?
I already spoke on the NVCP V-SYNC vs. in-game V-SYNC point earlier in this thread:wist7 wrote:Should i use v-sync and in-game limiter?
Now I don't know which are recommenced settings.
Battle(non)sense prefers to use V-SYNC in-game with G-SYNC, as it's more convenient to disable it in-game without closing and relaunching, and there is a slight possibility in his estimation that V-SYNC may (rarely) include further optimizations beyond the NVCP solution.jorimt wrote:Possibly increased stutter (micro or otherwise) and/or slightly more input lag due to possible extra buffer/flip queue behavior using the in-game solution. But, granted, this would be extremely rare.EeK wrote:Aside from tearing, what other "anomalous behavior" should we be looking out for when testing in-game VSync vs. NVCP VSync?
Beyond that and tearing, the issues are theoretical, because 99% of the time, there's likely little practical difference between NVCP V-SYNC and in-game V-SYNC when pairing it with G-SYNC. I just view it as safer to use NVCP V-SYNC over in-game to cover those 1% of possible instances.
As for Chris' mention of in-game V-SYNC having "other optimizations" (with or without G-SYNC), I'm not saying what he suggests doesn't exist, I just don't personally have any direct evidence of this in my testing (or general experience) to either confirm or deny that.