All about V-sync back pressure lag and pre-rendered frames

Discussion in 'Videocards - NVIDIA GeForce Drivers Section' started by IzanagiSato, Dec 14, 2019.

  1. IzanagiSato

    IzanagiSato New Member

    Messages:
    3
    Likes Received:
    0
    GPU:
    GTX 1070 8GB GDDR5
    1.) What exactly is “v- sync back pressure lag”? If it can be interpreted as a container that is gradually filled with excess frames (from what I understood), I’m curious—Is the ‘size’ of this container dependent on the game/application or is it something more universal? Perhaps dependent on the rig/PC? I’m assuming the ‘bigger’ this container is, the longer the potential lag could be? If this is the case, I’d assume The Witcher 3 has a very large ‘container’ as the input lag there is downright atrocious when I’m running uncapped.

    2.) Another thing is, does pre-rendered frame limit have any bearing on this? For example, in Nvidia’s Control Panel, there’s the Low Latency Mode, which has three options. Off, On, and Ultra. From what I can understand, Off lets the game queue frames freely, On is set at 1 (which is what is recommended when using the low-latency vsync trick), and then Ultra, which from my understanding is 0.

    Does setting this to ‘Ultra’ then help in making sure that there’ll never be a ‘vsync back pressure lag’?

    3.) How does MPRF = 0 differ from setting one's frame rate cap below their monitor's refresh rate?
     
    Last edited: Dec 14, 2019
  2. jorimt

    jorimt Active Member

    Messages:
    56
    Likes Received:
    19
    GPU:
    EVGA 1080 Ti FTW3
    It occurs with double buffer and (certain forms of) triple buffer V-SYNC when framerates are sustained above the refresh rate because each frame's render time is beyond the monitor's display time to show tear-free.

    For instance, let's say you've enabled V-SYNC on a 60Hz monitor, but your framerate can otherwise be sustained at 300 FPS.

    The fastest a 60Hz monitor can scan in a full, tear-free frame is 16.6ms, but with a framerate of 300, an average frame is rendered (and ready to be displayed) in 3.3ms, which means virtually all the frames (so long as the framerate is sustained at this level) are going to be ready too soon for that 60Hz monitor to display in real-time, tear-free.

    So what does V-SYNC do in this scenario? It displays each frame (regardless of its render time) in 16.6ms intervals instead.

    With this process continually occurring over a period of frames, though frames are shown in a perfect, unbroken sequence (so long as the framerate is sustained above the refresh rate), what you're seeing is at least 2 frames in the past (usually more), as your inputs were effectively being read while each frame was rendered (in the case of 300 FPS) at 3.3ms, but forced to show in intervals of 16.6ms per regardless.

    For V-SYNC, this form of input lag can be eliminated by simply setting an FPS limit slightly below the refresh rate, which forces each frame to render within the display time of the monitor, so instead of your inputs being read at 3.3ms and being displayed at 16.6ms per, they're effectively being read and each frame is being rendered (and then displayed) at 16.6ms instead.

    Admittedly oversimplified (and it doesn't even cover what happens with FPS below the refresh rate with V-SYNC), but that's the gist.

    V-SYNC input lag and pre-rendered frames input lag are entirely separate (the pre-rendered frames queue is still in effect, even with V-SYNC OFF), so it's accumulative when V-SYNC is enabled, at least in scenarios where the framerate is sustained above the refresh rate.

    Technically, so long as your framerate is sustained above the set FPS cap (V-SYNC or no V-SYNC), the pre-rendered frames queue typically doesn't apply. So, effectively, in this scenario, an FPS limiter is also MPRF "0."

    Also, any sort of pre-rendered frames setting typically only takes effect in scenarios with fluctuating (aka uncapped) framerates and/or in GPU-Bound situations, and even then, you're only looking at roughly a 1 frame reduction in input lag on average with these settings enabled (V-SYNC input lag prevention nets you more input lag reduction than anything else system/display-side).
     
    IzanagiSato likes this.
  3. IzanagiSato

    IzanagiSato New Member

    Messages:
    3
    Likes Received:
    0
    GPU:
    GTX 1070 8GB GDDR5
    Okay. This makes a lot of sense now. I've always thought they were practically the same. It was only after reading some more stuff that I started to think they were different, and you just confirmed it. Thanks, jorimt.

    Wait. Hold on. Isn't the entire point of capping one's FPS is to prevent it from going above the cap? I know it can fluctuate very slightly but it's more consistently below or at the set cap (at least with RTSS)... So I'm confused. How does this happen? That a framerate is sustained above the cap? Or did you mean that when one can sustain it above the cap when it is uncapped? Like, for example, if I play a certain game uncapped and it fluctuates between 80-110 FPS, but then I cap it (preferably using RTSS) to 60?
     
  4. jorimt

    jorimt Active Member

    Messages:
    56
    Likes Received:
    19
    GPU:
    EVGA 1080 Ti FTW3
    Right; just like with standalone V-SYNC, it simply means the framerate must otherwise be able to sustain itself above the refresh rate when uncapped.

    So, same here, only the framerate must be able to sustain itself above the set FPS limit when uncapped, otherwise there would be nothing to "cap" (limiters aren't doing anything until there is an otherwise higher average framerate to limit, which is why RTSS can only reduce V-SYNC input lag and improve frame pacing when it is the limiting factor, for instance).
     
    Last edited: Dec 15, 2019
    IzanagiSato likes this.

  5. RealNC

    RealNC Ancient Guru

    Messages:
    3,122
    Likes Received:
    1,347
    GPU:
    EVGA GTX 980 Ti FTW
    Think of frame times, not frame rates. If you set a 100FPS cap, what you are really setting is a 10 millisecond frame time lower limit. If a frame is rendered in less than 10ms, for example 7ms, the frame limiter will block the game for the remaining 3ms. If frames take longer than 10ms to render though, then the limiter does nothing; the game is unable to reach the FPS cap.
     
    IzanagiSato likes this.
  6. IzanagiSato

    IzanagiSato New Member

    Messages:
    3
    Likes Received:
    0
    GPU:
    GTX 1070 8GB GDDR5
    Hmmm. This is strange, though. I've tested a few games. And even though I can run those games above my refresh rate uncapped, setting NVCP's 'Low Latency Mode' to Ultra (which I assume is MRPF 0) still further minimizes the input lag. So what gives?

    I've been combining both MRPF 0 and RealNC's Low-lag Vsync (capping slightly below refresh rate), and they actually complement each other. Again, despite being able to run my FPS above my refresh rate consistently (when uncapped).
     
  7. jorimt

    jorimt Active Member

    Messages:
    56
    Likes Received:
    19
    GPU:
    EVGA 1080 Ti FTW3
    For one, I did say "typically," and secondly, how do you know it "still further minimizes input lag"?

    Was you're GPU usage at 99% >, even with the FPS limit at points?

    Because when we're talking about a single frame of input lag difference here, especially at higher refresh rates (granted, you have yet to mention your monitor's refresh rate), "results" can quickly enter the subjective, edging into the placebo if we're not careful.

    Battle(non)sense did test this when it first released, and even with V-SYNC OFF, in non-GPU-bound situations, and when compared to a standalone FPS limit, Ultra actually had slightly higher input lag when paired with an FPS limit:



    That said, this is the problem with pre-rendered frames settings in general; with V-SYNC, there is either V-SYNC input lag or there isn't, but with pre-rendered frames queue settings, it can depend on the system specs, the system load at any given point (framerate, GPU/CPU usage), and its interaction with the particular game engine (also, some game engines and/or game APIs, like DX12 and Vulkan, don't allow LLM to manipulate the pre-rendered frames queue at all, by the way).
     

Share This Page