PC Latency - Vsync with/without Framerate cap

[2mg]

60Hz monitor, no VRR, NVCPL LLM set to Ultra, otherwise stock.

Black Myth: Wukong, Low settings 1080p, no Raytracing, DLSS Balanced, Reflex Auto, GPU never goes above ~60%.

Monitoring the "PCL (av)" with Nvidia's performance overlay.

PCL with Vsync ON and 60fps cap = ~50ms
PCL with Vsync ON and 120fps cap = ~90ms
*Limiter is in-game.

Why the latency increase?
1. Shouldn't Vsync (regardless of fps cap) simply not allow GPU to render more than 60fps by itself, aka doesn't Vsync on 60hz imply the 60fps cap?
2. If it does allow the GPU to draw more than 60fps, shouldn't only the newest frames be presented and old discarded?
3. Is this how the game handles excess frames or Vsync type (double/triple buffer), or is this just down to how Vsync and fps caps work together?

[Sz3ypy]

If you dont want extra latency i think is must be less FPS then monitor refresh rate

[2mg]

If you dont want extra latency i think is must be less FPS then monitor refresh rate

I've just tried the same thing with Lies of P, unfortunately PCL is 0ms over there, so I can't confirm this, would like to see if Chief/RealNC can chime in.

Tho both games with PresentMon show "Display Latency" ~20ms without Vsync and ~60ms with Vsync, where NV perf overlay goes more than that in Wukong.

PS: I'm aware of 59-59.95fps cap and such tricks.

[Katzenwerfer_MX]

I will preface this by saying I'm not the most knowledgeable on the technical details, so I recommend you verify anything I mention.

1. Shouldn't Vsync (regardless of fps cap) simply not allow GPU to render more than 60fps by itself, aka doesn't Vsync on 60hz imply the 60fps cap?

Standard vsync synchronizes the GPU present rate to the display's refresh rate. It doesn't stall the GPU rendering rate directly and instead creates "backpressure".
The GPU still needs to have somewhere to render a frame, which is where buffers come into play. Once available buffers are full and waiting for the monitor to refresh, the GPU has nowhere to put a new frame and is forced to idle. This is why you see the FPS lock to the refresh rate since the GPU is essentially waiting for a buffer to be cleared so it can start working on the next one.

2. If it does allow the GPU to draw more than 60fps, shouldn't only the newest frames be presented and old discarded?

In standard vsync, the buffers act as a "first-in, first-out" queue. If the GPU is fast, it fills the queue, and the monitor displays the frames in the order they were finished. Because the frames sit in the queue waiting for their turn to be displayed, your inputs get effectively queued, and you don't see them reflected instantly, which is the well-known input latency commonly associated with vsync.
Nowadays there are workarounds with vendor technology like NVIDIA Fast Sync and API features like Vulkan's mailbox present mode and whatever equivalent there is for modern DXGI (which I'm pretty sure Special K enables by default).

3. Is this how the game handles excess frames or Vsync type (double/triple buffer), or is this just down to how Vsync and fps caps work together?

With a limiter, you are engaging in similar behavior to what NVIDIA Reflex does under a standard vsync scenario, which is to minimize the number of queued frames and target just-in-time delivery of them. It's more or less the same trick described in the low-lag vsync article.
https://blurbusters.com/howto-low-lag-vsync-on/
In your case, setting a limit of 120 would imply one extra frame of latency under standard vsync. Though somewhat redundant, try enabling Fast Sync, and you might be able to get no added latency with the same limit. Though, on second thought, ensuring Reflex is turned on should be more than enough.

[2mg]

...

Modern Vsync tricks can drop frames and display the newest one aka no backpressure, but keep at least one frame buffered in case the monitor finishes with current frame and requests a new one.

Fast Sync afaik doesn't buffer anything - issue is that you need to have rock solid FPS multiples of your display Hz for it to work, otherwise you'll get uneven framepacing (a form stutter/judder).

While I understand Vsync backpressure, the fact that GPU usage falls down from unlocked FPS when you turn on Vsync means that GPU is rendering less frames?

[Katzenwerfer_MX]

While I understand Vsync backpressure, the fact that GPU usage falls down from unlocked FPS when you turn on Vsync means that GPU is rendering less frames?

Measuring performance with usage % metrics can be misleading since, depending on how it's calculated, it being high or low won't necessarily reflect whether the hardware is rendering faster or slower.
On a side note. I've noticed with a limiter, metrics don't necessarily reflect the real maximum throughput you could have from the hardware in a real scenario. I'm not sure why, but I'm guessing lower frame times have an overhead that physical hardware can't handle.
Personally, I wouldn't worry too much about it unless you are being GPU-limited in the game you are playing.

[daemonjax]

To reduce input latency with vsync you cap fps slightly below the ACTUAL hz of your lcd panel. You say 60hz, but the actual is probably 59.995ish -- so, in that example, you'd want to cap it using RTSS to 59.994. Or you could use CRU to make it whatever hz you want (within reason) -- that's especially useful if you want to use a framecap at the driver level for whatever reason, which only accepts integer values. So in that case you'd make a custom res at 60.003 hz (or whatever) and cap to 60 (or whatever) in the gpu driver.

This works because it starves the buffers. This goes back to the dx9 era (dead space 1 was basically unplayable with vsync on unless you did this), except the best we could do back then was cap at 59 fps on 60-ish hz panels, which was less than ideal. Sometimes capping at 60hz seemed to work well-enough too for some reason, and that was nice. FRAPS had a fps limiter and a lot of people used that, but there was another lesser known one that worked way better for this for reasons unknown... I forgot what it was called, and I'll probably never remember. EDIT: it was dxtory

[2mg]

To reduce input latency with vsync you cap fps slightly below the ACTUAL hz of your lcd panel. You say 60hz, but the actual is probably 59.995ish -- so, in that example, you'd want to cap it using RTSS to 59.994. Or you could use CRU to make it whatever hz you want (within reason) -- that's especially useful if you want to use a framecap at the driver level for whatever reason, which only accepts integer values. So in that case you'd make a custom res at 60.003 hz (or whatever) and cap to 60 (or whatever) in the gpu driver.

This works because it starves the buffers. This goes back to the dx9 era (dead space 1 was basically unplayable with vsync on unless you did this), except the best we could do back then was cap at 59 fps on 60-ish hz panels, which was less than ideal. Sometimes capping at 60hz seemed to work well-enough too for some reason, and that was nice. FRAPS had a fps limiter and a lot of people used that, but there was another lesser known one that worked way better for this for reasons unknown... I forgot what it was called, and I'll probably never remember. EDIT: it was dxtory

I'm aware of this ancient technique, we also now have ULLM and Reflex and whatnot.

My question was simply why does the PC LAT indicator go higher if I don't restrict the FPS to 60fps when using Vsync.

[Katzenwerfer_MX]

My question was simply why does the PC LAT indicator go higher if I don't restrict the FPS to 60fps when using Vsync.

In my previous post, think I forgot you mentioned you aren't using VRR. Last I knew, without VRR, Reflex should still allow at most 1 frame of latency.

[2mg]

My question was simply why does the PC LAT indicator go higher if I don't restrict the FPS to 60fps when using Vsync.

In my previous post, think I forgot you mentioned you aren't using VRR. Last I knew, without VRR, Reflex should still allow at most 1 frame of latency.

Good to know, but that's another thing.

I've read your post above, and I'm not using % metrics, it's using ms (milliseconds) if it matters.