Frametime fluctuations when v-synced in PC games?

Everything about displays and monitors. 120Hz, 144Hz, 240Hz, 4K, 1440p, input lag, display shopping, monitor purchase decisions, compare, versus, debate, and more. Questions? Just ask!
User avatar
jorimt
Posts: 882
Joined: 04 Nov 2016, 10:44

Re: Frametime fluctuations when v-synced in PC games?

Post by jorimt » 25 Feb 2019, 15:36

EchoDissolve wrote: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).
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

User avatar
RealNC
Site Admin
Posts: 2916
Joined: 24 Dec 2013, 18:32
Contact:

Re: Frametime fluctuations when v-synced in PC games?

Post by RealNC » 26 Feb 2019, 03:34

jorimt wrote: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
SteamGitHubStack OverflowTwitter
The views and opinions expressed in my posts are my own and do not necessarily reflect the official policy or position of Blur Busters.

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

Re: Frametime fluctuations when v-synced in PC games?

Post by jorimt » 26 Feb 2019, 09:05

Thanks for the heads up, I'll use that link from now on. I've corrected the links in my article as well.
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

andrelip
Posts: 41
Joined: 21 Mar 2014, 17:50

Re: Frametime fluctuations when v-synced in PC games?

Post by andrelip » 26 Feb 2019, 12:01

jorimt wrote:
EchoDissolve wrote: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...

User avatar
Chief Blur Buster
Site Admin
Posts: 6709
Joined: 05 Dec 2013, 15:44

Re: Frametime fluctuations when v-synced in PC games?

Post by Chief Blur Buster » 26 Feb 2019, 12:20

jorimt wrote: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).
andrelip wrote: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:

Image

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:

Image

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):

Image
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

       To support Blur Busters:
       • Official List of Best Gaming Monitors
       • List of G-SYNC Monitors
       • List of FreeSync Monitors
       • List of Ultrawide Monitors

EchoDissolve
Posts: 6
Joined: 25 Feb 2019, 10:37

Re: Frametime fluctuations when v-synced in PC games?

Post by EchoDissolve » 26 Feb 2019, 12:32

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.

User avatar
Chief Blur Buster
Site Admin
Posts: 6709
Joined: 05 Dec 2013, 15:44

Re: Frametime fluctuations when v-synced in PC games?

Post by Chief Blur Buster » 26 Feb 2019, 13:43

You're welcome!

We're the only public site that covers the display pipeline in such depth outside of manufacturers (or scientific journals)
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

       To support Blur Busters:
       • Official List of Best Gaming Monitors
       • List of G-SYNC Monitors
       • List of FreeSync Monitors
       • List of Ultrawide Monitors

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

Re: Frametime fluctuations when v-synced in PC games?

Post by jorimt » 26 Feb 2019, 15:00

andrelip wrote: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).
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