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

Talk about NVIDIA G-SYNC, a variable refresh rate (VRR) technology. G-SYNC eliminates stutters, tearing, and reduces input lag. List of G-SYNC Monitors.
User avatar
jorimt
Posts: 1139
Joined: 04 Nov 2016, 10:44

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

Post by jorimt » 11 Apr 2020, 12:52

bapt337 wrote:
11 Apr 2020, 11:18
So you mean LLM ultra reduce pre-rendered frame to 1
By 1; if the pre-rendered frames queue is currently 3 (it fluctuates at any given point depending on a variety of factors), it will reduce it to 2, if it's at 1, it will reduce it to 0 (aka show it "just-in-time), and so on. Highly depends on the system, game, and GPU usage at any given point. Needless to say, LLM is by no means a panacea.
bapt337 wrote:
11 Apr 2020, 11:18
but also LLM does nothing to directly prevent or reduce vsync input lag,
Correct, they aren't directly related. LLM does the same thing with V-SYNC off as it does with V-SYNC on.
bapt337 wrote:
11 Apr 2020, 11:18
How much should i cap fps for 60hz with LLM ultra then?
For direct input lag reduction purposes, LLM is only for uncapped, GPU-bound scenarios; if your framerate is currently limited by an FPS cap, and your GPU usage isn't maxed, LLM will effectively do nothing to reduce input lag further.
bapt337 wrote:
11 Apr 2020, 11:18
EDIT: also ive notice curious behavior with vulkan engine in RDR2, i use adaptive sync from nvidia control panel, vsync in game disable, no fps limit in game.
If i dont use any cap, only adaptive sync, frametime fluctuate between 15ms and 17ms.
If i use 61 fps cap from RTSS (for 60hz) + adaptive sync,the frametime is just flat 16.6ms.
Is this because RTSS have good frame pacing or maybe directly related with vulkan engine? maybe it doesnt like too much frame?
Adaptive sync as in G-SYNC, or adaptive sync as in Adaptive V-SYNC? Either way, RTSS limits FPS by frametime, so as long as your framerate stays at the set RTSS limit, you'll be getting near perfect frametimes, which is why you're seeing what you're seeing. This should apply to any game that RTSS can be used in.

Also, framerate limiters cap the framerate, but don't prevent tearing, whereas V-SYNC doesn't limit the framerate (it instead uses the VBLANK to throttle it at the max refresh rate, ultimately causing additional input lag), but prevents tearing. Both have different roles.
(jorimt: /jor-uhm-tee/)
Author: Blur Busters "G-SYNC 101" Series

Display: Acer Predator XB271HU OS: Windows 10 Pro MB: ASUS ROG Maximus X Hero CPU: i7-8700k GPU: EVGA GTX 1080 Ti FTW3 RAM: 32GB G.SKILL TridentZ @3200MHz

bapt337
Posts: 27
Joined: 10 Apr 2020, 12:54

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

Post by bapt337 » 11 Apr 2020, 13:57

jorimt wrote:
11 Apr 2020, 12:52
By 1; if the pre-rendered frames queue is currently 3 (it fluctuates at any given point depending on a variety of factors), it will reduce it to 2, if it's at 1, it will reduce it to 0 (aka show it "just-in-time), and so on. Highly depends on the system, game, and GPU usage at any given point. Needless to say, LLM is by no means a panacea.
Allright thanks for the clearance, but there is no more pre rendered frame setting in nvidia control panel, how set pre rendered frame then?
Adaptive sync as in G-SYNC, or adaptive sync as in Adaptive V-SYNC? Either way, RTSS limits FPS by frametime, so as long as your framerate stays at the set RTSS limit, you'll be getting near perfect frametimes, which is why you're seeing what you're seeing. This should apply to any game that RTSS can be used in.
I mean adaptive vsync, and your right, this behavior happen in all game until i dont cap it with RTSS.
Also, framerate limiters cap the framerate, but don't prevent tearing, whereas V-SYNC doesn't limit the framerate (it instead uses the VBLANK to throttle it at the max refresh rate, ultimately causing additional input lag), but prevents tearing. Both have different roles.

that's where scanline sync is just usefull litterally the g-sync of the poor :p
For direct input lag reduction purposes, LLM is only for uncapped, GPU-bound scenarios; if your framerate is currently limited by an FPS cap, and your GPU usage isn't maxed, LLM will effectively do nothing to reduce input lag further.
Allright when you say LLM is only for uncapped you mean uncapped + vsync ? no uncapped vsync off cause if im right there is no perendered frame with vsync off then LLM dont apply

EDIT : after some research it seems LLM is the new pre-rendered frame setting, so to ultra its the minimum pre-rendered frame.
Ive find also prerendered frame work aslo with vsync off, so my question is:
Should it be good to use LLM ultra combined with scanline sync?

User avatar
jorimt
Posts: 1139
Joined: 04 Nov 2016, 10:44

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

Post by jorimt » 11 Apr 2020, 14:52

bapt337 wrote:
11 Apr 2020, 13:57
Allright thanks for the clearance, but there is no more pre rendered frame setting in nvidia control panel, how set pre rendered frame then?
"Low Latency Mode" = pre-rendered frames setting. It used to be called "Maximum pre-rendered frames." It's just a label change with less options now.

In non-G-SYNC scenarios, LLM "On" = MPRF "1," and LLM Ultra = MPRF "1" + "just in time" frame delivery (in uncapped, GPU-bound scenarios).
bapt337 wrote:
11 Apr 2020, 13:57
that's where scanline sync is just usefull litterally the g-sync of the poor :p
Yes, correct, Scanline Sync is essentially tearline steering that attempts the same thing as G-SYNC, but at a fixed refresh rate.
bapt337 wrote:
11 Apr 2020, 13:57
Allright when you say LLM is only for uncapped you mean uncapped + vsync ? no uncapped vsync off cause if im right there is no perendered frame with vsync off then LLM dont apply
Contrary to popular opinion, the pre-rendered frames queue still actually applies to uncapped V-SYNC off as well. E.g. you can still get GPU input lag (due to a sustained increase in the pre-rendered frames queue) with, say, 300 FPS V-SYNC off @144Hz if it maxes out your GPU, at which point you could set an FPS limit that keeps the GPU below 99% usage to prevent it.
bapt337 wrote:
11 Apr 2020, 13:57
EDIT : after some research it seems LLM is the new pre-rendered frame setting, so to ultra its the minimum pre-rendered frame.
Ive find also prerendered frame work aslo with vsync off, so my question is:
Should it be good to use LLM ultra combined with scanline sync?
Only for when your framerate drops below your refresh rate will LLM Ultra do anything when you're using Scanline Sync.

So that said, it should be fine to leave it on, but obviously, you don't want your FPS dipping below your refresh rate with Scanline Sync, and further, you ideally don't want to get in a situation where you have to resort to LLM in the first place.

TLDR; whether it's always in effect or not, for non-G-SYNC scenarios, it's typically safe to leave LLM at "On" or "Ultra."
(jorimt: /jor-uhm-tee/)
Author: Blur Busters "G-SYNC 101" Series

Display: Acer Predator XB271HU OS: Windows 10 Pro MB: ASUS ROG Maximus X Hero CPU: i7-8700k GPU: EVGA GTX 1080 Ti FTW3 RAM: 32GB G.SKILL TridentZ @3200MHz

bapt337
Posts: 27
Joined: 10 Apr 2020, 12:54

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

Post by bapt337 » 11 Apr 2020, 15:07

jorimt wrote:
11 Apr 2020, 14:52
Only for when your framerate drops below your refresh rate will LLM Ultra do anything when you're using Scanline Sync
Thanks for this i see now, of course my fps never drop below refresh rate with scanline, then i will try LLM ultra first, as it say on another forum its like a "real time" prerendered frame, so if frametime is stable and dont fluctuate with scanline, without stutter i will stay to ultra if no will try "on".

I would say, try ultra, if smooth stay to this, if no, back to "on".

A last question does set LLM to off (no queued frame limit) and cap fps to 61 (for 60hz) is the same as prerendered frame = 1 (LLM on) ?

User avatar
jorimt
Posts: 1139
Joined: 04 Nov 2016, 10:44

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

Post by jorimt » 11 Apr 2020, 15:29

bapt337 wrote:
11 Apr 2020, 15:07
A last question does set LLM to off (no queued frame limit) and cap fps to 61 (for 60hz) is the same as prerendered frame = 1 (LLM on) ?
A framerate limited by an FPS cap (above or below the refresh rate) + < 98% GPU usage + LLM "Off" typically = 0 pre-rendered frames.

The pre-rendered frames queue typically only kicks in when there isn't a guaranteed frametime; aka when the framerate is fluctuating and not limited by an FPS cap.

In other words, keeping your framerate limited by an FPS cap at all times is actually better than LLM Ultra, since the latter only reduces the PRF queue, whereas the former typically eliminates it.
(jorimt: /jor-uhm-tee/)
Author: Blur Busters "G-SYNC 101" Series

Display: Acer Predator XB271HU OS: Windows 10 Pro MB: ASUS ROG Maximus X Hero CPU: i7-8700k GPU: EVGA GTX 1080 Ti FTW3 RAM: 32GB G.SKILL TridentZ @3200MHz

bapt337
Posts: 27
Joined: 10 Apr 2020, 12:54

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

Post by bapt337 » 11 Apr 2020, 16:09

jorimt wrote:
11 Apr 2020, 15:29
bapt337 wrote:
11 Apr 2020, 15:07
A last question does set LLM to off (no queued frame limit) and cap fps to 61 (for 60hz) is the same as prerendered frame = 1 (LLM on) ?
A framerate limited by an FPS cap (above or below the refresh rate) + < 98% GPU usage + LLM "Off" typically = 0 pre-rendered frames.

The pre-rendered frames queue typically only kicks in when there isn't a guaranteed frametime; aka when the framerate is fluctuating and not limited by an FPS cap.

In other words, keeping your framerate limited by an FPS cap at all times is actually better than LLM Ultra, since the latter only reduces the PRF queue, whereas the former typically eliminates it.
ALlright thanks again i see now, its like we dont give the choice to the CPU, we give only the extra frame needed to be sure have the lowest frame in queue, that's logic.

Ive find nearly same result, with adaptive vsync on + LLM on + uncapped FPS vs adaptive sync +LLM off + fps cap RTSS at 61 fps.
Same input lag, same flat frametime, i guess its nearly the same since LLM on = 1 pre-rendered frame, and 61 fps cap give 1 extra frame.
ive test it with DX11 in GTA5. on other hand, adaptiv sync+ LLM off + uncapped fps give inconscistent frametime, even if i set 120fps cap with RTSS for 60hz monitor i get frametime fluctuation, so fps or max pre-rendered frame higher than 1 (or higher than 61 fps) give frametime fluctuation, and exact same behavior in RDR2 with vulkan API, anything higher than 61 fps give frametime fluctation with adptive vsync on.

this test was done with adaptive vsync on on 60hz monitor:

uncapped fps + LLM ON = flat frametime
uncapped fps + LLM off = frametime fluctuate
61 fps cap (RTSS) + LLM off = flat frametime
120 fps cap (RTSS) + LLM off = frametime fluctuate

So it seems the only thing who resolve the frametime fluctution is max fps +1 refresh rate or max pre rendered frame =1
anything higher give this behavior, whatever API used (dx11 / vulkan)
curious behavior, i assume more fps or max pre rendered frame should bring smoothness, but higher input lag,
in my case, it bring frametime fluctuation and sort of microstutter.
Maybe i missed something, but it should be the opposite behavior, should have less smooth with pre rendered frame max =1 or +1 fps cap, and more smoothness when using higher max pre rendered frame or more fps

fo scanline sync, ive havnt notice any difference with LLM ultra or off, i prefer let it off and give scanline all the frame it need without any cap or something, if im right scanline need all the frame to work well since it already use the lowest input lag there is no reason to cap fps or use LLM IMO

User avatar
jorimt
Posts: 1139
Joined: 04 Nov 2016, 10:44

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

Post by jorimt » 11 Apr 2020, 16:46

bapt337 wrote:
11 Apr 2020, 16:09
Ive find nearly same result, with adaptive vsync on + LLM on + uncapped FPS vs adaptive sync +LLM off + fps cap RTSS at 61 fps.
Same input lag, same flat frametime, i guess its nearly the same since LLM on = 1 pre-rendered frame, and 61 fps cap give 1 extra frame.
Not quite; "1 frame" of input lag is different than "1 frame" of the average framerate in this case. The pre-rendered frames queue is also entirely separate of whether the framerate is above or below the refresh rate, or if sync is on or off.

What makes the difference with the pre-rendered frames queue is whether the system has a guaranteed frametime target; if the framerate is fluctuating, it doesn't, if the framerate is continually limited by a set FPS cap (and you're not GPU-bound), it does.

It doesn't matter if the refresh rate is 60Hz or 144Hz, or if the framerate is 61 FPS or 145 FPS, only whether the given framerate is fluctuating or not, and is being limited by an FPS cap or not (again, so long as you're also not GPU-bound).
bapt337 wrote:
11 Apr 2020, 16:09
i assume more fps or max pre rendered frame should bring smoothness, but higher input lag
A higher pre-rendered frame queue typically does provide more smoothness at the cost of higher input lag due to increased buffering.
bapt337 wrote:
11 Apr 2020, 16:09
in my case, it bring frametime fluctuation and sort of microstutter.
Maybe i missed something, but it should be the opposite behavior, should have less smooth with pre rendered frame max =1 or +1 fps cap, and more smoothness when using higher max pre rendered frame or more fps
That's because I think you're still conflating refresh rate, specific framerates, and syncing methods with the pre-rendered frames queue.
bapt337 wrote:
11 Apr 2020, 16:09
fo scanline sync, ive havnt notice any difference with LLM ultra or off, i prefer let it off and give scanline all the frame it need without any cap or something, if im right scanline need all the frame to work well since it already use the lowest input lag there is no reason to cap fps or use LLM IMO
Scanline Sync is the exception here, since, as far as I'm aware, it essentially sets an RTSS FPS cap at the current max refresh rate, and then allows the user to manually "steer" the tearline offscreen into the VBLANK. So, yes, LLM typically isn't going to have an effect, even if enabled.
(jorimt: /jor-uhm-tee/)
Author: Blur Busters "G-SYNC 101" Series

Display: Acer Predator XB271HU OS: Windows 10 Pro MB: ASUS ROG Maximus X Hero CPU: i7-8700k GPU: EVGA GTX 1080 Ti FTW3 RAM: 32GB G.SKILL TridentZ @3200MHz

bapt337
Posts: 27
Joined: 10 Apr 2020, 12:54

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

Post by bapt337 » 11 Apr 2020, 17:24

jorimt wrote:
11 Apr 2020, 16:46
What makes the difference with the pre-rendered frames queue is whether the system has a guaranteed frametime target; if the framerate is fluctuating, it doesn't, if the framerate is continually limited by a set FPS cap (and you're not GPU-bound), it does.
It doesn't matter if the refresh rate is 60Hz or 144Hz, or if the framerate is 61 FPS or 145 FPS, only whether the given framerate is fluctuating or not, and is being limited by an FPS cap or not (again, so long as you're also not GPU-bound).
I understand but i used this with adptive vsync so wahtever fps cap i use im never gpu bound im like 70% gpu usage and frametime fluctuate when i uncapp fps with LLM off, i understand pre render frame is not related with refresh rate and system have to render a frame fast enough to guaranteed/susatain frametime if ive right understand, thats why 1 max prerender frame hit performance cause system (CPU?) have to render frame faster cause only 1 frame can be queued.
But i dont understand why i get frametime fluctuation with adaptiv vsync on + LLM off + uncapped fps, im not gpu bounded, but fps are unlocked thats right, but gpu usage is 70% so it have headroom to render the frame fast enough even more with LLM off whic allow the maximum pre rendered frame, so IMO frametime should be flat, you said it, up max pre rendered frame queue bring smoothness, ive done this with LLM off, gpu not bound and frametime still fluctuating, but no more when i cap to 61 fps, but if i set LLM to "on" which is like pre rendered frame 1 which should more hit perfomance than LLM off (cause higher frame queued= higher performance) give a flat frametime and it should be the opposite so im surly missing something but i feel really close to understand ![/quote]

Thanks for yout time :)

EDIT: when i mean frametime fluctuate, framerate DONT fluctuate, framerate is always 60 but frametime fluctuate


[/quote]

spacerocktraveler
Posts: 6
Joined: 06 Nov 2018, 04:58

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

Post by spacerocktraveler » 11 Apr 2020, 18:43

jorimt wrote:
19 Mar 2020, 21:40
spacerocktraveler wrote:
19 Mar 2020, 20:06
What games do you play and what settings do you have your monitor at?
Lately, mostly SP games when I have the time; Black Mesa and Hollow Knight atm.

As for monitor settings, I'm a bit of a casual calibration enthusiast, so my settings would not be popular for the majority, and could be considered boring by typical gamer standards. For instance, I calibrate all of my displays to 100 nits ("Brightness 15" on the monitor), primarily because I also need this monitor to be color/luminance correct for work unrelated to gaming.

Contrast is set to the default "50", and all the extra settings are disabled. Colour Temp is set to "User," Saturate is at default "100," and "6-axis color" is also at default. Calibration was done with an i1Display Pro + DisplayCal software, and targets a 6500k, 2.2 gamma, 100 nit sRGB standard.
too dark for me :) i'm just happy enjoying ulmb w/ vsync on

User avatar
jorimt
Posts: 1139
Joined: 04 Nov 2016, 10:44

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

Post by jorimt » 11 Apr 2020, 19:02

bapt337 wrote:
11 Apr 2020, 17:24
EDIT: when i mean frametime fluctuate, framerate DONT fluctuate, framerate is always 60 but frametime fluctuate
Again, that's because V-SYNC on its own doesn't "lock" frametime, whereas an RTSS FPS limit does.
(jorimt: /jor-uhm-tee/)
Author: Blur Busters "G-SYNC 101" Series

Display: Acer Predator XB271HU OS: Windows 10 Pro MB: ASUS ROG Maximus X Hero CPU: i7-8700k GPU: EVGA GTX 1080 Ti FTW3 RAM: 32GB G.SKILL TridentZ @3200MHz

Post Reply