Frametime fluctuations when v-synced in PC games?

[jorimt]

One last thing I'm curious about: What's the need for the RTSS lock on top of the half-refresh? Without the lock I saw frame times locked to 33.33ms, but input lag did seem worse than with the lock. Happy to hear a technical explanation if you have one here -- always like to learn.

For a lack of better terms (and a much more involved explanation), V-SYNC throttles the frametime periodically (a.k.a. inconsistently) to keep the framerate synced to the VBLANK (prevents tearing), while an RTSS limit sets a consistent frametime limit (doesn't prevent tearing, just limits average framerate by target frametime), which improves frame pacing in this 30 FPS lock (and most other) scenario(s).

[RealNC]

You need to download Nvidia Inspector and use the non-adaptive 1/2 refresh option there:
https://ci.appveyor.com/project/Orbmu2k ... /artifacts

That site is just a CI (Continuous Integration) platform. It deletes builds after a while. And the builds aren't actually even official, but they are created every time there's a commit in Git. So they're considered development snapshots.

The author uploads official releases on github now:

https://github.com/Orbmu2k/nvidiaProfil ... r/releases

[jorimt]

Thanks for the heads up, I'll use that link from now on. I've corrected the links in my article as well.

[andrelip]

One last thing I'm curious about: What's the need for the RTSS lock on top of the half-refresh? Without the lock I saw frame times locked to 33.33ms, but input lag did seem worse than with the lock. Happy to hear a technical explanation if you have one here -- always like to learn.

For a lack of better terms (and a much more involved explanation), V-SYNC throttles the frametime periodically (a.k.a. inconsistently) to keep the framerate synced to the VBLANK (prevents tearing), while an RTSS limit sets a consistent frametime limit (doesn't prevent tearing, just limits average framerate by target frametime), which improves frame pacing in this 30 FPS lock (and most other) scenario(s).

From what I've learned all it does is wait for the Vertical Blank Interrupt (that is dispatched once the raster enters the vertical blank interval) to swap the front and back buffer. The throttle is actually the GPU blocking the rendering (by wait/sleep) until the back buffer is empty again after swap. So in theory it shouldn't be inconsistently since the time elapsed between VBI should is fixed and stable...

[Chief Blur Buster]

For a lack of better terms (and a much more involved explanation), V-SYNC throttles the frametime periodically (a.k.a. inconsistently) to keep the framerate synced to the VBLANK (prevents tearing), while an RTSS limit sets a consistent frametime limit (doesn't prevent tearing, just limits average framerate by target frametime), which improves frame pacing in this 30 FPS lock (and most other) scenario(s).

From what I've learned all it does is wait for the Vertical Blank Interrupt (that is dispatched once the raster enters the vertical blank interval) to swap the front and back buffer. The throttle is actually the GPU blocking the rendering (by wait/sleep) until the back buffer is empty again after swap. So in theory it shouldn't be inconsistently since the time elapsed between VBI should is fixed and stable...

Both of these are different terminological ways of saying essentially the same thing.
(With minor nitpicks on misinterpretations)

I'll approach this visually, using diagrams (which I had Jorim help create, to specifications).

VSYNC = Vertical Synchronization

Which can refer to two different things
-- the computer-side of waiting for the blanking interval (aka "VSYNC ON" versus "VSYNC OFF"). It doesn't remove the VBI from the signal.
-- or the signal-side (VSYNC is part of the VBI between refresh cycles). The VSYNC part of a signal always exists, no matter what, even in GSYNC/FreeSync mode.

Now, let's look at what 60Hz VSYNC ON looks like at the frame delivery level -- at the GPU output, one pixel row being transmitted at a time out of the GPU output, with one frame per refresh cycle:



More diagrams can be seen in the second half of Understanding Scanout Via High Speed Video. A display is in VBI (Vertical Blanking Interval) when a refresh cycle finishes scanning out but before the next refresh cycle begins. This can also be the cable perspective (GPU output) or at the panel perspective (panel scanout), and the two may or may not be in sync with each other (the signal can be buffered by the monitor, for a completely different refreshing sequence, such as a different velocity or different direction scanout, or a more global refreshing method like DLP).

For simplicity, we'll only worry about the GPU output level as whatever the display does afterwards is typically beyond GPU's control (processing, GtG pixel response, monitor buffering behaviour, etc).

Now, if a software is running in VSYNC ON, rendering can continue in the background (up to "Max Prerendered Frames"), but the finished framebuffers will "wait for VSYNC" before being displayed. If the prerendered frames are maxed-out, rendering is blocked. But until then, games can keep rendering in the background future frames, while the currently-finished frame is waiting for VSYNC (VBI) before being displayed in next refresh cycle.

Without interrupting the still currently-transmitting front buffer (creating tearing) like you can for VSYNC OFF, as follows:

180 frames per second at 60 Hz:



For variable refresh rate, the blanking interval will vary in size to temporally pad-out the refresh cycles. The blanking interval still contains VSYNC, but now the blanking interval is variable in size to support lower refresh rates (without needing to change scan velocity or frame delivery velocity, which remains lowest latency at the highest scanout velocity of the max Hz)

How the monitor handles the varying mechanism will vary from monitor to monitor and sync tech to tech, but all of them have the same thing in common; scanout at max-Hz, with temporal padding between scanouts. This is true for both NVIDIA's native GSYNC and for AMD's FreeSync, VESA Adaptive Sync, HDMI 2.1 VRR, and all other variants of variable refreshing.

Anything that's not a visible scanout is considered the vertical blanking interval (pause between refresh cycles), which in itself is varying in order to allow the refresh cycle timing to be asynchronous. Now, for FreeSync specifically, that's actually a real realtime dynamically varying Vertical Back Porch value (as seen in a Custom Resolution Utility) -- a tiny component of a VBI.

Here's a diagram of 100 frames per second at 144 Hz variable refresh rate (GSYNC/FreeSync):

[EchoDissolve]

This forum is awesome! I love technical explanations and now I’ve got a better answer than I ever expected. Thanks to all for contributing.

[Chief Blur Buster]

You're welcome!

We're the only public site that covers the display pipeline in such depth outside of manufacturers (or scientific journals)

[jorimt]

From what I've learned all it does is wait for the Vertical Blank Interrupt (that is dispatched once the raster enters the vertical blank interval) to swap the front and back buffer. The throttle is actually the GPU blocking the rendering (by wait/sleep) until the back buffer is empty again after swap. So in theory it shouldn't be inconsistently since the time elapsed between VBI should is fixed and stable...

Explaining double buffer V-SYNC behavior is not my forte (or primary interest), hence the "For a lack of better terms (and a much more involved explanation)" line in the post you quoted. But he asked me, so I obliged.

Point is, on a 60Hz monitor being fed frames that continuously exceed the refresh rate, double buffer V-SYNC will only display 60 of them per second, and deliver them at 16.6ms per, regardless whether some frames are rendered (a.k.a. ready to be delivered) faster than 16.6ms at any point (which they can be periodically with double buffer V-SYNC until they are ultimately throttled, repeatedly).

Thus, double buffer V-SYNC does not make for a consistent frametime limiter, while an RTSS FPS limit slightly below the refresh rate does (and prevents the throttling/over-queuing behavior of V-SYNC as well).