PC Latency - Vsync with/without Framerate cap

[RealNC]

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

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?

It's a 60Hz monitor. That means a 120FPS cap does nothing and you're hitting full vsync buffering and backpressure lag.

With a 60FPS cap, you can get the game to stop hitting the vsync ceiling. I'd recommend Special K's "latent sync" to this cap for best results.

If you ever wondered why people cap their FPS below Hz with VRR, it's to prevent exactly this from happening. It also works without VRR of course, the difference is that without VRR you get some hiccups/judder (unless you use latent sync.)

[2mg]

It's a 60Hz monitor. That means a 120FPS cap does nothing and you're hitting full vsync buffering and backpressure lag.

With a 60FPS cap, you can get the game to stop hitting the vsync ceiling. I'd recommend Special K's "latent sync" to this cap for best results.

If you ever wondered why people cap their FPS below Hz with VRR, it's to prevent exactly this from happening. It also works without VRR of course, the difference is that without VRR you get some hiccups/judder (unless you use latent sync.)

So 60FPS cap creates less backpressure, but why compared to 120FPS cap, if unneeded frames are discarded anyway/Vsync implementation uses the same number of buffers and there are no queue buffers because of ULLM?

Regarding VRR, wasn't that because you needed ~3FPS of safety margin to stop VRR from disengaging, and isn't that now fixed with Reflex (or if game lacks Reflex, if LLM is set to Ultra, it does the same)?

[RealNC]

So 60FPS cap creates less backpressure, but why compared to 120FPS cap, if unneeded frames are discarded anyway/Vsync implementation uses the same number of buffers and there are no queue buffers because of ULLM?

Frames are never discarded and ULLM does not prevent vsync backpressure. ULLM only prevents pre-rendered frames from being processed by the CPU in advance while the GPU is not actually ready to render any of them. The only way to prevent rendered frame buffers from being filled and as a result the game blocked at the worst moment (right after reading player input) is to prevent that pileup using an FPS cap to "starve" the vsync frame buffering mechanism.

For frames to be discarded you need to either use Fast Sync, or have a game that supports Vulkan and mailbox presentation mode, or run the game in windowed mode with a legacy frame presentation mode with vsync off and have DWM discard frames.

Regarding VRR, wasn't that because you needed ~3FPS of safety margin to stop VRR from disengaging, and isn't that now fixed with Reflex (or if game lacks Reflex, if LLM is set to Ultra, it does the same)?

The -3 thing isn't really to prevent VRR from disengaging when using vsync. It's to prevent vsync backpressure. A -3FPS cap works just as well without VRR. But of course then a -3FPS cap will produce judder, which doesn't happen with VRR.

In your case, a 60FPS cap just about manages to do it probably because your display is either 60Hz or slightly above, but it's not guaranteed to work at all times. You'd need to instead find out your exact refresh rate and cap your FPS very precisely 0.01FPS below that:

https://blurbusters.com/howto-low-lag-vsync-on/
https://forums.guru3d.com/threads/the-t ... st-5380262

Although the best way to do this is to use either RTSS scanline sync, or even better Special K latent sync with tearing mode set to (Off low latency) and a render queue of 1 frame max, like this:

latent_sync.png (133.27 KiB) Viewed 935 times

On a 60Hz display, you'd use the "1/1" scan mode though. This configuration is for preventing vsync backpressure while still having motion that's as smooth as if it was fully vsynced without any FPS cap. This is the method I use when VRR is not an option.

[2mg]

Frames are never discarded and ULLM does not prevent vsync backpressure. ULLM only prevents pre-rendered frames from being processed by the CPU in advance while the GPU is not actually ready to render any of them. The only way to prevent rendered frame buffers from being filled and as a result the game blocked at the worst moment (right after reading player input) is to prevent that pileup using an FPS cap to "starve" the vsync frame buffering mechanism.

For frames to be discarded you need to either use Fast Sync, or have a game that supports Vulkan and mailbox presentation mode, or run the game in windowed mode with a legacy frame presentation mode with vsync off and have DWM discard frames.

Indeed, I mixed Fast Sync and company with non-discarding Vsync backpressure.

However, please correct me again if I'm wrong, but backpressure causes GPU to sleep.

When a buffer "opens up", the difference between 60 and 120FPS caps (both with 60FPS Vsync) is that with 120FPS capped GPU renders the frame 2x faster into that buffer and goes to sleep again, so I still don't see 120FPS cap having more backpressure/latency since number of buffers used are the same between 60 and 120FPS - unless it's exactly that 2x speed @120 what PC LAT considers as having ~2x more latency compared to @60?
Something like "GPU is done 2x faster at 120, meaning you're waiting for that frame to actually be displayed for 2x longer" which misses/ignores the part that it will actually get displayed to you at 60FPS anyway but it's just sitting in that buffer for longer from GPU's perspective?

Or maybe 60FPS cap just flows more neatly, as rendered frames align with the entire Vsync chain, but again 120FPS just renders it faster into a buffer and goes to sleep, buffer-wise aka latency it's exactly the same?

PS: I'm aware of buffer-starving techniques, even before VRR came to be, but thanks for reminding me and writing a guide about RTSS/SK sync.

[RealNC]

When a buffer "opens up", the difference between 60 and 120FPS caps (both with 60FPS Vsync) is that with 120FPS capped GPU renders the frame 2x faster into that buffer and goes to sleep again, so I still don't see 120FPS cap having more backpressure/latency since number of buffers used are the same between 60 and 120FPS - unless it's exactly that 2x speed @120 what PC LAT considers as having ~2x more latency compared to @60?

An FPS cap doesn't affect how fast the GPU is rendering each frame. It only blocks the game from presenting rendered frames faster than the FPS cap. This blocking is what prevents vsync backpressure because that blocking prevents the game from starting to work on the next frame too early.

When a game starts preparing a new frame, what happens is that it first reads the current input state from mouse/kb/controller, then creates a new game scene based on that input state, and then submit that scene to the GPU for rendering. When all frame buffers are filled (because the game is submitting these scenes to the GPU too fast and thus the GPU renders them into those frame buffers,) vsync will block the game after this new scene has been prepared for rendering, not before. That means this old yet to be rendered scene is sitting around, and by the time vsync unblocks it so it can be submitted to the GPU for rendering, the input it's based on is very old. When frames you finally see on the screen are based on old input, you get lag. This is what vsync backpressure is. All frame buffers are filled and as a result the game is prevented from submitting new frames to render, but this prevention happens at the worst possible time - after the game has already sampled player input. So in the end, every single frame you see has gone through this and is based on old input, on top of the fact that it's been sitting around in a frame buffer for a while.

An FPS limiter prevents all this from happening.

Now, if your FPS limit is above your refresh rate, this means the FPS limiter is doing nothing. At 60Hz, each frame is presented every 16.7ms. A 120FPS limit only kicks-in if the presentation interval is smaller than 8.3ms. So it doesn't do anything. Yes, the very first few frames will trigger the limiter, but it doesn't matter. After the frame buffers are filled (2 or 3 frames) vsync backpressure kicks in. Again, keep in mind that the FPS limiter doesn't control how fast the GPU is rendering. It only controls how often the game is allowed to present a new frame. Blocking on frame presentation is not the best place to do frame limiting, but it still is a hell of a lot better than the place vsync blocks at, and it still prevents backpressure. This is for external FPS limiters. In-game limiters can do this block at an even better spot in the chain, reducing latency even further than external limiters. (For example by blocking within the game's code, right before sampling player input.)

[2mg]

Now, if your FPS limit is above your refresh rate, this means the FPS limiter is doing nothing. At 60Hz, each frame is presented every 16.7ms. A 120FPS limit only kicks-in if the presentation interval is smaller than 8.3ms. So it doesn't do anything. Yes, the very first few frames will trigger the limiter, but it doesn't matter. After the frame buffers are filled (2 or 3 frames) vsync backpressure kicks in. Again, keep in mind that the FPS limiter doesn't control how fast the GPU is rendering. It only controls how often the game is allowed to present a new frame. Blocking on frame presentation is not the best place to do frame limiting, but it still is a hell of a lot better than the place vsync blocks at, and it still prevents backpressure. This is for external FPS limiters. In-game limiters can do this block at an even better spot in the chain, reducing latency even further than external limiters. (For example by blocking within the game's code, right before sampling player input.)

Thanks for the vsync backpressure quick course, but the crux of my question is related specifically to FPS>Hz & Vsync+limiter scenario.

Obviously, the limiter is doing something, which is why PC LAT goes up almost 2x, which I still don't get why is happening, and is the latency actually increased or is it just how PC LAT calculation is done?

So this is more of a "should I use a limiter set at FPS=Hz when specifically using non-VRR Vsync?"

[RealNC]

Obviously, the limiter is doing something, which is why PC LAT goes up almost 2x, which I still don't get why is happening, and is the latency actually increased or is it just how PC LAT calculation is done?

Are you sure it the limiter that increases PCLAT? I suspect it will be the same with no cap at all.

So this is more of a "should I use a limiter set at FPS=Hz when specifically using non-VRR Vsync?"

Yes. Although it should be slightly below Hz. Or even better, use a frame limiter made for this specific purpose (Special K latent sync or RTSS scanline sync.)

[2mg]

Are you sure it the limiter that increases PCLAT? I suspect it will be the same with no cap at all.

Yes, as I stated in my first post, I can post screenshots if needed.

So this is more of a "should I use a limiter set at FPS=Hz when specifically using non-VRR Vsync?"

Yes. Although it should be slightly below Hz. Or even better, use a frame limiter made for this specific purpose (Special K latent sync or RTSS scanline sync.)

Sure, but that is about Vsync optimization and set it aside for now, my question is more directed to PC LAT and your question above, aka should you always and at least use the limiter with Vsync (limit FPS=Hz), aka don't set in-game limiter to unrestricted since it seems to increase PC LAT?

I hope we can get to the bottom of PC LAT behavior.

[RealNC]

Sure, but that is about Vsync optimization and set it aside for now, my question is more directed to PC LAT and your question above, aka should you always and at least use the limiter with Vsync (limit FPS=Hz), aka don't set in-game limiter to unrestricted since it seems to increase PC LAT?

That's the first time you mention an in-game limiter. What those might do is up to them.

[2mg]

Sure, but that is about Vsync optimization and set it aside for now, my question is more directed to PC LAT and your question above, aka should you always and at least use the limiter with Vsync (limit FPS=Hz), aka don't set in-game limiter to unrestricted since it seems to increase PC LAT?

That's the first time you mention an in-game limiter. What those might do is up to them.

I edited my post to reflect this.

So it's a bit of a black box situation?
Meaning users should always check if setting in-game limiters to FPS=Hz has a beneficial effect on latency?