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: 1140
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:03

spacerocktraveler wrote:
11 Apr 2020, 18:43
too dark for me :) i'm just happy enjoying ulmb w/ vsync on
Ha, indeed, but you asked, so I answered. Good to hear you've settled with a configuration you're happy with.
(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, 19:21

jorimt wrote:
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.
allright so vsync ON ITS OWN doesnt lock frametime, but lock framerate, right?
and add fps cap 61 (for 60hz) or set max pre rendered frame to 1 with vsync on lock frametime.
ayway it seems to many frame always bring frametime fluctuation, ive cap fps (RTSS) to 120 with adaptive sync on and frametime fluctuate, no problem when cap to 61. uncapped same result.
i think its what we call frame pacing.

User avatar
jorimt
Posts: 1140
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:55

bapt337 wrote:
11 Apr 2020, 19:21
allright so vsync ON ITS OWN doesnt lock frametime, but lock framerate, right?
There isn't a simple answer to this, and really, it's complete off subject for this thread, but I'll quote a couple of (grossly simplified) excerpts from the comments section of my article regarding this (ignore anything that refers to "G-SYNC"; the below applies to any form of sync with framerates sustained above the refresh rate):
Even though [V-SYNC] visibly “caps” the framerate to the refresh rate, double buffer V-SYNC (with or without G-SYNC) doesn’t prevent delayed frame delivery like a framerate limiter does, but, in fact, causes it.

For instance, at a sustained 200 FPS, each frame is rendered in 5ms. However at 144Hz with G-SYNC and/or V-SYNC, the fastest each frame can be delivered tear-free to the display is 6.9ms. So, with 144Hz G-SYNC + V-SYNC at 200 FPS with no FPS limiter (which effectively behaves like standalone V-SYNC at that point, as G-SYNC can no longer adjust the refresh rate to the framerate), each frame will be rendered in 5ms, but each will be delayed 1.9ms before being delivered as to match the max 144Hz scanout cycle of 6.9ms per. This delay adds up over a period of frames, eventually over-queuing the buffers, and thus causes the extra input lag.

A framerate limiter, however (in-game or external), ensures that the maximum render time of each frame is within the maximum delivery time of the given refresh rate, preventing this issue entirely.
And further...
The higher the FPS is above the refresh rate with V-SYNC, the worse the input lag is, as your inputs are being read at lower and lower render times, but being forced to be shown at the same intervals of the current max refresh rate regardless.
Basically, V-SYNC with framerates above the refresh rate are always a big no-no input lag-wise, and an FPS limit set below the refresh rate is recommended.

FYI, V-SYNC with a 59 FPS limit @60Hz is much lower lag than uncapped adaptive V-SYNC @60Hz. Also, Nvidia adaptive V-SYNC is merely V-SYNC "on" with framerates above the refresh rate, which then switches to V-SYNC "off" with framerates below the refresh rate.

If you want to discuss this subject further, feel free to create a new thread on it (same goes for frametime stability and pacing in general as well), but I've about exhausted my ability to convey it here in the context of our current discussion, which is actually about LLM.

Getting back to the LLM subject, to sum-up, you typically don't need it for Scanline Sync, and it's only primarily useful in GPU-bound situations.
(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 » 12 Apr 2020, 03:22

jorimt wrote:
11 Apr 2020, 19:55
bapt337 wrote:
11 Apr 2020, 19:21
allright so vsync ON ITS OWN doesnt lock frametime, but lock framerate, right?
There isn't a simple answer to this, and really, it's complete off subject for this thread, but I'll quote a couple of (grossly simplified) excerpts from the comments section of my article regarding this (ignore anything that refers to "G-SYNC"; the below applies to any form of sync with framerates sustained above the refresh rate):
Even though [V-SYNC] visibly “caps” the framerate to the refresh rate, double buffer V-SYNC (with or without G-SYNC) doesn’t prevent delayed frame delivery like a framerate limiter does, but, in fact, causes it.

For instance, at a sustained 200 FPS, each frame is rendered in 5ms. However at 144Hz with G-SYNC and/or V-SYNC, the fastest each frame can be delivered tear-free to the display is 6.9ms. So, with 144Hz G-SYNC + V-SYNC at 200 FPS with no FPS limiter (which effectively behaves like standalone V-SYNC at that point, as G-SYNC can no longer adjust the refresh rate to the framerate), each frame will be rendered in 5ms, but each will be delayed 1.9ms before being delivered as to match the max 144Hz scanout cycle of 6.9ms per. This delay adds up over a period of frames, eventually over-queuing the buffers, and thus causes the extra input lag.

A framerate limiter, however (in-game or external), ensures that the maximum render time of each frame is within the maximum delivery time of the given refresh rate, preventing this issue entirely.
And further...
The higher the FPS is above the refresh rate with V-SYNC, the worse the input lag is, as your inputs are being read at lower and lower render times, but being forced to be shown at the same intervals of the current max refresh rate regardless.
Basically, V-SYNC with framerates above the refresh rate are always a big no-no input lag-wise, and an FPS limit set below the refresh rate is recommended.

FYI, V-SYNC with a 59 FPS limit @60Hz is much lower lag than uncapped adaptive V-SYNC @60Hz. Also, Nvidia adaptive V-SYNC is merely V-SYNC "on" with framerates above the refresh rate, which then switches to V-SYNC "off" with framerates below the refresh rate.

If you want to discuss this subject further, feel free to create a new thread on it (same goes for frametime stability and pacing in general as well), but I've about exhausted my ability to convey it here in the context of our current discussion, which is actually about LLM.

Getting back to the LLM subject, to sum-up, you typically don't need it for Scanline Sync, and it's only primarily useful in GPU-bound situations.
Really thanks for the clearance its all clear now, if you use 144hz monitor + vsync then cap to 200 fps, we are ok, the time betwwen each frame is not the same at 200 than 144 so it cannnot render the frame in the perfect timing that's why frametime fluctutate, cause the frame is like shift at a moment.
and that's why, even with uncapped fps, i get consistent frametime when LLM= ON (pre rendered frame =1) because there is only one frame in the buffer then it cannot have a lag between at least 2 frame (cause only one in buffer) right?

its all clear, i can only cap at 61 cause if i cap under 60 with adptive sync it result like vsync off (tearing).
I could try regular vsync instead.

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

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

Post by jorimt » 12 Apr 2020, 08:58

bapt337 wrote:
12 Apr 2020, 03:22
Really thanks for the clearance its all clear now, if you use 144hz monitor + vsync then cap to 200 fps, we are ok, the time betwwen each frame is not the same at 200 than 144 so it cannnot render the frame in the perfect timing that's why frametime fluctutate, cause the frame is like shift at a moment.
My last post was about V-SYNC input lag, which has nothing directly to do with pre-rendered frames. And what you're talking about now is overall frametime performance, which is also separate from LLM settings in this context.

I suggest you become more acquainted with the basics before trying to understand pre-rendered frames.
(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 » 12 Apr 2020, 11:57

jorimt wrote:
12 Apr 2020, 08:58
My last post was about V-SYNC input lag, which has nothing directly to do with pre-rendered frames. And what you're talking about now is overall frametime performance, which is also separate from LLM settings in this context.
I was saying because you said :
Even though [V-SYNC] visibly “caps” the framerate to the refresh rate, double buffer V-SYNC (with or without G-SYNC) doesn’t prevent delayed frame delivery like a framerate limiter does, but, in fact, causes it.

For instance, at a sustained 200 FPS, each frame is rendered in 5ms. However at 144Hz with G-SYNC and/or V-SYNC, the fastest each frame can be delivered tear-free to the display is 6.9ms. So, with 144Hz G-SYNC + V-SYNC at 200 FPS with no FPS limiter (which effectively behaves like standalone V-SYNC at that point, as G-SYNC can no longer adjust the refresh rate to the framerate), each frame will be rendered in 5ms, but each will be delayed 1.9ms before being delivered as to match the max 144Hz scanout cycle of 6.9ms per. This delay adds up over a period of frames, eventually over-queuing the buffers, and thus causes the extra input lag.

A framerate limiter, however (in-game or external), ensures that the maximum render time of each frame is within the maximum delivery time of the given refresh rate, preventing this issue entirely.
i understand what you mean, VSYNC input lag is about how much frame are rendred and uncapped framerate add an additonal frame input lag cause it over queuing the buffer, or add delay cause it give different frametime than the monitor frametime (uncapped fps)
And this input lag have to be added with the pre-rendered frame input lag which give overall input lag.
Ive already look a lot on google and i know people here really knwo what they say.
Thnaks for help anyway

Nester47
Posts: 1
Joined: 30 Apr 2020, 06:27

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

Post by Nester47 » 30 Apr 2020, 06:32

Dear friend's!
Please explain me what config should i use on my pc to minimize input lag and avoid tearing/stuttering? -
1080gtx + i7 8700 + aoc g2460pg.
Now playing warzone and modern warfare.
Thanks a lot!☺️

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

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

Post by jorimt » 30 Apr 2020, 10:57

Nester47 wrote:
30 Apr 2020, 06:32
Dear friend's!
Please explain me what config should i use on my pc to minimize input lag and avoid tearing/stuttering? -
1080gtx + i7 8700 + aoc g2460pg.
Now playing warzone and modern warfare.
Thanks a lot!☺️
G-SYNC on + NVCP V-SYNC on + Low Latency Mode on + in-game V-SYNC off + in-game fullscreen (not borderless or windowed) + -3 RTSS FPS limit (141 FPS).
(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

flaviowolff
Posts: 20
Joined: 08 Jun 2018, 09:18

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

Post by flaviowolff » 02 May 2020, 02:02

Sorry for not reading the whole thread, but what’s the current conclusion on the best practices regarding LLM for normal monitors (no VRR), when:

A) using the Low lag vsync method (-0.01 rtss cap +vsync on);
B) vsync off + rtss -0.01 cap, and
C) vsync off + uncapped

Thank you very much

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

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

Post by jorimt » 02 May 2020, 09:41

flaviowolff wrote:
02 May 2020, 02:02
Sorry for not reading the whole thread, but what’s the current conclusion on the best practices regarding LLM for normal monitors (no VRR), when:

A) using the Low lag vsync method (-0.01 rtss cap +vsync on);
B) vsync off + rtss -0.01 cap, and
C) vsync off + uncapped

Thank you very much
Generally, for engines that support LLM (DX12 and Vulkan don't)...

A) Ultra (note; assuming your FPS is sustained at your limit, LLM will only take effect when your FPS drops below it)
B) Ultra (same applies as above)
C) Ultra (same applies as above)

Basically, Ultra should be fine to leave enabled globally in most non-VRR scenarios, but if you spot any weird behavior, you can drop it down to "On" (which doesn't have the additional "just-in-time" frame delivery component; On = MPRF 1, Ultra = MPRF 1 + just-in-time delivery).

LLM is only primarily useful in reducing input lag in situations where your GPU usage is maxed. In situations where your FPS is limited by a cap, and said cap is preventing your GPU from maxing out, LLM is effectively doing nothing to further reduce input lag.
(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