Page 17 of 22

Re: Driver 441.08: Ultra-Low Latency Now with G-SYNC Support

Posted: 12 Jan 2020, 08:41
by 1000WATT
poppe wrote:
11 Jan 2020, 15:39
jorimt wrote:
11 Jan 2020, 14:50
You didn't say whether you had a VRR setup, but with G-SYNC, "Ultra" is basically an automatic FPS limiter + MPRF "1."

So, say you limit your FPS to 141 @144Hz with Nvidia's new Max Frame Rate option, and then enabled "Ultra" LLM as well; the ~138 auto limit will take effect instead of your set 141 FPS limit, which is why I recommend setting LLM to "On" when using it in combo with G-SYNC and an in-game or external FPS limiter.

For non-G-SYNC though, an external or in-game limiter + "Ultra" should be fine, as it doesn't have the auto-capping behavior when used with fixed refresh rates.
I do use G-SYNC @ 240 Hz

Reason I'm so confused about latency mode is because of Battlenonsense testing:

https://i.imgur.com/u3ysznI.png
https://i.imgur.com/5HSeMvs.png

Ultra latency mode gives higher input lag even though it "autocaps" FPS. But when GPU load is high then Ultra is better..
So I thought setting Ultra globally for casual games with an FPS cap for DX12 games (since the autocap don't work there) and then for serious games like CS:GO I'll just use LLM "On" with ingame FPS limiter.
in the picture 1 comparison of the in-game limiter with LLM "Ultra". for overwatch, an in-game limiter is better than rtss and nvidia limiter.

Re: Driver 441.08: Ultra-Low Latency Now with G-SYNC Support

Posted: 12 Jan 2020, 09:13
by 1000WATT
https://www.blurbusters.com/gsync/gsync ... mment-9288
jorimt
Battle(non)sense just did a video on this:

https://youtu.be/W66pTe8YM2s

It appears Nvidia’s new limiter is effectively a match to the RTSS limiter in both input lag and frametime performance. That said, good in-game limiters still have lower input lag.


He compared the battlefield in-game limiter to the nvidia limiter. frame time when using rtss is still more stable.

Re: Driver 441.08: Ultra-Low Latency Now with G-SYNC Support

Posted: 12 Jan 2020, 10:07
by jorimt
janos666 wrote:
12 Jan 2020, 00:02
I don't understand why nVidia didn't try to force this new setting over the game's own numbers, at least with Ultra and popular game engines.
As far as I'm aware on that, if a game engine doesn't allow external override of the pre-rendered frames queue (yes, I believe Frostbite being one of them), Nvidia quite literally can't at the driver-level, even if they wanted to. It's the reason NULL doesn't currently work with DX12 or Vulkan, both of which manage that aspect on their own.
janos666 wrote:
12 Jan 2020, 00:02
And I guess the 'V-Sync lag' (in case of uncapped fps with G-Sync+V-Sync) would still be higher with Ultra (if that could even work since it's not regular V-Sync)
G-SYNC + V-SYNC + sustained FPS above the refresh rate is virtually the same as standalone V-SYNC actually. The only difference between the two in this scenario, is that whenever the framerate drops below the refresh rate, the former immediately begins syncing the display to the GPU, whereas the latter doesn't.
janos666 wrote:
12 Jan 2020, 00:02
I vaguely theorized something like Ultra might tries to "starve" the GPU a little bit (sacrificing some fps) to avoid the regular ~100% utilization scenario.
Those like RealNC have suggested something similar...

Theoretically, it's possible using an external FPS limiter like RTSS; you would set a desired FPS limit offset (say, -3), and then the limiter would monitor the frametime of each frame, and then dynamically limit the FPS slightly below it (e.g. if the average fluctuating FPS is currently 113, the limiter would cap to 110, etc), preventing max GPU usage, and thus reducing the pre-rendered frames queue more than LLM would on it's own. Whether this is practically possible is another question entirely though.

--------
1000WATT wrote:
12 Jan 2020, 09:13
He compared the battlefield in-game limiter to the nvidia limiter. frame time when using rtss is still more stable.
Battle(non)sense claims otherwise. Watch at the 4:33 mark here:
https://youtu.be/W66pTe8YM2s?t=273

I quote:
Then you can simply use the new framerate limiter feature inside the Nvidia Control Panel to not only get the same input delay as you would get with RTSS, but also enjoy the same perfectly stable frametimes, and so consistent input delay.

Re: Driver 441.08: Ultra-Low Latency Now with G-SYNC Support

Posted: 12 Jan 2020, 12:59
by 1000WATT
jorimt wrote:
12 Jan 2020, 10:07
1000WATT wrote:
12 Jan 2020, 09:13
He compared the battlefield in-game limiter to the nvidia limiter. frame time when using rtss is still more stable.
Battle(non)sense claims otherwise. Watch at the 4:33 mark here:
https://youtu.be/W66pTe8YM2s?t=273

I quote:
Then you can simply use the new framerate limiter feature inside the Nvidia Control Panel to not only get the same input delay as you would get with RTSS, but also enjoy the same perfectly stable frametimes, and so consistent input delay.
Yes, he said so, but in the video itself I did not find a place where he tested it. Only https://imgur.com/cDlcznY

I checked on my own several times. And now I can confidently say that the difference is so insignificant that it seems to me that I'm just making an elephant out of a fly. :lol:
https://imgur.com/s8y6I79

Re: Driver 441.08: Ultra-Low Latency Now with G-SYNC Support

Posted: 12 Jan 2020, 15:39
by RealNC
The new nvidia limiter is a big buggy right now. I've seen a couple people have the issue where after a reboot, the limiter becomes unable to cap to the configured target anymore. Instead, it varies between -10 and -8 compared to your target.

So use carefully right now.

Re: Driver 441.08: Ultra-Low Latency Now with G-SYNC Support

Posted: 04 Feb 2020, 21:00
by hkngo007
I currently play with gsync ON + vsync OFF + -3fps/hz cap + NULL OFF.

My understanding is the input lag benefit would not apply to my setup even tho I'm using gsync as the tested results are with vsync ON?

Can anyone clarify?

Re: Driver 441.08: Ultra-Low Latency Now with G-SYNC Support

Posted: 06 Feb 2020, 16:53
by RealNC
hkngo007 wrote:
04 Feb 2020, 21:00
I currently play with gsync ON + vsync OFF + -3fps/hz cap + NULL OFF.

My understanding is the input lag benefit would not apply to my setup even tho I'm using gsync as the tested results are with vsync ON?

Can anyone clarify?
Correct. With vsync off, a -3 cap is done to prevent tearing, not to prevent input lag.

Re: Driver 441.08: Ultra-Low Latency Now with G-SYNC Support

Posted: 12 Feb 2020, 08:34
by poppe
I just noticed NULL doesn't autocap FPS anymore (Driver 442.19).
So what's really the difference between NULL and "On" then? Since there's supposedly no input lag difference.

Re: Driver 441.08: Ultra-Low Latency Now with G-SYNC Support

Posted: 12 Feb 2020, 09:03
by janos666
Ultra should still limit the fps, I think. It's probably a bug in the driver (sometimes it doesn't engage for some DX 9-11 games like HALO:MCC, I am not sure if this randomness is limited to the fps capping or the entire LLM functionality). And Ultra was never supposed to work with Vulkan or DX12. Although the FPS slider (fps limiter V3) works with those as well, so my general settings are Ultra + 117 fps limit on the slider.

What I am wondering about if it's normal to have tearing with a low fps cap and G-Sync without V-Sync. When I testes this, I had to go down from 120 (for 120 Hz) to 60-80 and some tearing still remained (always very close to the bottom of the screen, in the HUD area). I wonder if this is different between module based proprietary G-Sync and industry standard HDMI 2.1 VRR or people who say they have no tearing with G-Sync and low fps cap (V-Sync=off) simply aren't perceptive enough to notice the occasional tearline at the bottom. The question is if this difference (if any) has any latency implications with G-Sync+V-Sync and a tight cap (like the usual -3 fps). Could this mean that V-Sync is engaged more often for this setup?

Re: Driver 441.08: Ultra-Low Latency Now with G-SYNC Support

Posted: 12 Feb 2020, 09:37
by jorimt
poppe wrote:
12 Feb 2020, 08:34
I just noticed NULL doesn't autocap FPS anymore (Driver 442.19).
So what's really the difference between NULL and "On" then? Since there's supposedly no input lag difference.
As far as I'm aware, the NULL auto-cap with G-SYNC only engages in (non-DX12/Vulkan) games that allow external manipulation of the pre-rendered frames queue, so that could make support seem spotty from game to game. Could be wrong on this specific point though; Nvidia rarely provides specifics on this sort of thing, so it's difficult to gauge without in-depth user-side testing.

Also, I don't know of any difference between Low Latency "On" and "Ultra" other than the auto FPS limit with G-SYNC, but there is in non-G-SYNC scenarios.
janos666 wrote:
12 Feb 2020, 09:03
What I am wondering about if it's normal to have tearing with a low fps cap and G-Sync without V-Sync. When I testes this, I had to go down from 120 (for 120 Hz) to 60-80 and some tearing still remained (always very close to the bottom of the screen, in the HUD area).
Even with an RTSS limit? If so, that does seem atypical, unless the frametime was micro-spiking near constantly in that instance, which I find unlikely from your description.
janos666 wrote:
12 Feb 2020, 09:03
I wonder if this is different between module based proprietary G-Sync and industry standard HDMI 2.1 VRR
Possibly. I assume your display is G-SYNC compatible then? Officially or no? And through HDMI (aka the LG C9) or DisplayPort on a FreeSync monitor?

G-SYNC Compatible being entirely software drive, it is possible VRR performance isn't as "tight" from moment to moment in some scenarios when directly compared to G-SYNC with a module.
janos666 wrote:
12 Feb 2020, 09:03
The question is if this difference (if any) has any latency implications with G-Sync+V-Sync and a tight cap (like the usual -3 fps). Could this mean that V-Sync is engaged more often for this setup?
Battle(non)sense has already tested G-SYNC Compatible implementation on an officially compatible FreeSync display, and he found G-SYNC + V-SYNC + 138 FPS limit prevents V-SYNC input lag, so I'd say, no, actual V-SYNC behavior probably isn't engaging more in this configuration when compared directly to G-SYNC w/module.

That said, it could be safe to say that it's possible that the frametime compensation mechanic of the V-SYNC option with G-SYNC is having to engage more often with G-SYNC Compatible than with the G-SYNC module in like-for-like scenarios though.