good and bad with max prerender frames 1 vs 8 ?

Discussion in 'Videocards - NVIDIA GeForce Drivers Section' started by alexander1986, Apr 20, 2018.

  1. alexander1986

    alexander1986 Master Guru

    Messages:
    201
    Likes Received:
    21
    GPU:
    RTX 2060
    just curious here, for lowest input lag possible its best to go with max prerender 1 in nvidia drivers, correct? or are there situations where a higher number can actually lower input lag? or is the only benefit with higher numbers less stuttering?

    is it a good idea to just set it at 1 and be done with it, atleast if you want as low input lag as possible? would be interesting to know anyway what the differences are exactly and what running on 8 vs 1 does, exactly :D thanks for any help!
     
  2. janos666

    janos666 Ancient Guru

    Messages:
    1,648
    Likes Received:
    405
    GPU:
    MSI RTX3080 10Gb
    I bet this horse can never be dead enough and could always use some beating (unless something changes dramatically around all the queuing/sycing). :D
    I personally didn't really notice any stutter with the 1 setting but some games run at significantly higher frame rates with 2+ (might even 10-20% or so) which can make it look/feel significantly smoother by itself (though some games might not care at all, especially if they are bottle-necked by something which isn't even indirectly effected by this value).
    Also, it's hard (if not impossible in some cases) to know if it has any effect at all. For example, Frostbite 3 games will override this, no matter what you set in the NVCP (you can use the developer console inside the game though: renderaheadlimit).
     
  3. MrBonk

    MrBonk Guest

    Messages:
    3,385
    Likes Received:
    283
    GPU:
    Gigabyte 3080 Ti
    alexander1986 likes this.
  4. Mda400

    Mda400 Maha Guru

    Messages:
    1,089
    Likes Received:
    200
    GPU:
    4070Ti 3GHz/24GHz
    The setting can make a weak CPU that's paired with a powerful GPU perform better.

    The lower the value, the smaller amount of frames prepared by the CPU before sending to the GPU and lower input delay, but with lower framerates if the application is CPU-constrained.

    The more frames prepared by the CPU to send to the GPU and more consistent/higher framerates, but with more input delay.

    Essentially a frame preparation buffer for the CPU in the event the GPU driver is starved or bloated by the CPU.

    It can also solve micro-stuttering in some games that has the GPU waiting too long for frames to be sent by the CPU (by lowering this setting's value).
     
    Last edited: Apr 23, 2018
    alexander1986 likes this.

  5. RealNC

    RealNC Ancient Guru

    Messages:
    4,954
    Likes Received:
    3,234
    GPU:
    4070 Ti Super
    Not sure what the "CPU-prepared frames" thingy comes from. Pre-rendered frames, as the name suggests, means frames that have been pre-rendered already but are kept in a frame buffer queue to be displayed later.

    At least that's my interpretation of it, based on the name of this setting. On the AMD side, this is called "flip queue size", which further suggests this has nothing to do with "CPU-prepared frames", since frame buffer flipping operates on frame buffers that contain already rendered frames ready to be displayed. The message given in the control panel sounds more like an unfortunate wording to me. But, I could be talking out of my ass too, so, you know... :p

    (Edit from the future: I was talking out of my ass, it turns out. These really are CPU-prepared frames yet to be actually rendered by the GPU.)

    So basically, it seems this setting allows you to go even further with buffering than triple buffer. If that's the case, then higher values are only useful for non-interactive applications to guard against engine stalls. With a value of 8 for example, you can protect against stalls of up to 134ms. Real-time demos or 3D benchmarks for example that aren't interactive can benefit.

    You can induce "engine stalls" artificially to keep the pre-render buffers empty. This is what a frame limiter does, and by doing that, you can decrease input lag as if you were using a setting of 0. When you do that, it doesn't matter what this is set to. 1 or 8, it will behave as if it was 0, unless the game is unable to reach the frame cap, at which point the setting takes effect.

    This is what allows the low latency vsync trick to work.

    With that being said, I'm not aware of any real technical explanation on how this setting is actually implemented in the drivers. It looks like it controls how many frames are kept "in flight" when you do a present() call on them, since nowadays this is an asynchronous call, but how that's done exactly, I don't know.
     
    Last edited: Aug 19, 2019
  6. MaxiJazz

    MaxiJazz Member

    Messages:
    23
    Likes Received:
    0
    GPU:
    Geforce GTX 1070
    @RealNC

    Please explain for dumbs (like me).
    How exactly i can introduce difference with settings 1-8 on 144hz monitor?
    I need to use v-sync@60hz (if my config cant reach 144) or i need just limit my fps? (Or turn off v-sync and limiter?)
    Explain with examples please.
     
  7. Mda400

    Mda400 Maha Guru

    Messages:
    1,089
    Likes Received:
    200
    GPU:
    4070Ti 3GHz/24GHz
    Right, i forgot to say this setting really only matters when vsync is enabled and it makes more sense the way you laid it out where i'm thinking 'pre-rendered' meant 'pre-prepared' (by the CPU), but since this setting lies in the graphics driver, the GPU would have already rendered the frames and stores them until the buffer flips ;)

    With vsync lag in mind, If its DirectX, the buffer flips to the next sequentially created frame, but in OpenGL with triple buffering, the buffer can flip to the most recent frame created (which neither of these matter if you frame limit under the vsync cap, as you know).
     
    Last edited: Apr 27, 2018
  8. janos666

    janos666 Ancient Guru

    Messages:
    1,648
    Likes Received:
    405
    GPU:
    MSI RTX3080 10Gb
    To complicate this a little further, Frostbite3 (and possible other game engines) seems to override this value (maximum pre-redered frames \ flip-queue size --- as the VGA drivers call it) with it's own RenderDevice.RenderAheadLimit (at least that's how it looks like to me --- according to my limited experimentation with these --- but I can obviously be wrong) and this doesn't seem to have any direct relationship with V-sync (or any other custom sync tech). Regardless of *sync, a value of 1 seems to result in some framerate decrease (varying between random measurement noise range and up to ~10% or so, based on given hardware, game and who knows what else...) while a value above 2 doesn't seem to change anything (compared to the usual default = 2 and 0 usually meaning unconfigured=default [thus 2]). The CPU utilization seems to increase with 1 (compared to 2+). The CPU-time stats in Frotbite3 definitely go up a bit (although that could mean anything) and the GPU utilization usually drops from constant ~100% to ~97% or something (it's not resting at the ceiling but fluctuates around it, just a little lower at average --- of course this is with high quality settings in relatively demanding games and without a framerate cap...). And the fps drop from a setting of 1 tends to be bigger on less powerful CPUs (although I never really benchmarked this correctly, just noticed that the difference went down after upgrading to a new CPU with more cores and higher frequency but there are always driver and OS updates too, so...).
     
    Last edited: Apr 29, 2018
  9. Mda400

    Mda400 Maha Guru

    Messages:
    1,089
    Likes Received:
    200
    GPU:
    4070Ti 3GHz/24GHz
    If input lag is the consideration, then you want to put it on 1 globally and change on a per-application basis.
    Same would go for render-ahead limit in games that have that setting.

    It's mainly for games that tend to use the CPU more than the GPU, to give the CPU time to feed the GPU with enough work.
     
    Last edited: Apr 30, 2018
  10. TheDeeGee

    TheDeeGee Ancient Guru

    Messages:
    9,636
    Likes Received:
    3,413
    GPU:
    NVIDIA RTX 4070 Ti
    Setting to 1 also lowers Framerate.
     
    Dragondale13 likes this.

  11. Dragondale13

    Dragondale13 Ancient Guru

    Messages:
    1,527
    Likes Received:
    244
    GPU:
    GTX 1070 AMP! • H75
    Yup! I've been using 3 for everything since 391 drivers were released.
    Not set globally though.
    Input lag isn't as severe as it used to be.
     
  12. Isn't that the default?
     
  13. WhiteLightning

    WhiteLightning Don Illuminati Staff Member

    Messages:
    30,767
    Likes Received:
    3,937
    GPU:
    Inno3d RTX4070
    Im using 1 for years. I like the responsiveness on the mouse.
     
  14. Dragondale13

    Dragondale13 Ancient Guru

    Messages:
    1,527
    Likes Received:
    244
    GPU:
    GTX 1070 AMP! • H75
    Not for all games no.Nvidia changed that to app controlled under global.I'm assuming that was the reason, that's why I change it to 3 per app. and leave global at default.Why assume it's at 3 when I can just set it.
     
  15. RealNC

    RealNC Ancient Guru

    Messages:
    4,954
    Likes Received:
    3,234
    GPU:
    4070 Ti Super
    Set it to 8 in Inspector. Force vsync ON in the nvidia control panel. Then launch Fallout 4. In the main menu, move the mouse. The mouse cursor has huge input lag.

    Now quit the game and set MPRF to 1. Start Fallout 4 again, now the mouse cursor has very little input lag.
     
    MaxiJazz likes this.

  16. RealNC

    RealNC Ancient Guru

    Messages:
    4,954
    Likes Received:
    3,234
    GPU:
    4070 Ti Super
    Hm. Actually it also applies to vsync off. Witcher 3 is affected by it, for example. Force vsync OFF in the nvcp, set MPRF to 8 in profile inspector, disable all frame caps (make sure the in-game limiter is also off). The game becomes unplayable. You get over 8 frames of input lag.

    Set MPRF to 1, and the lag is gone.

    Other games on the other hand don't seem affected by it with vsync OFF, but are affected when using vsync ON.

    I kind of give up to make sense of it :p Setting it to 1 results in no FPS loss here, so that's what I've been using globally. Some people report it makes an FPS difference in some games, but when I test it, nothing. Same FPS. Probably because I'm on 1440p and most games are GPU-bound.

    The MPRF setting only seems to pile up frames when the GPU is maxed out, or when vsync is enabled. This is also true when using MPRF 1, since 0 isn't possible. There's more input lag when the GPU maxes out. However, this might become a non-issue for RTSS users in the future. Unwinder said he's going to add the "GPU throttling" option suggested some months ago in a future beta:

    https://forums.guru3d.com/threads/download-msi-afterburner-4-5-0.420564/page-3#post-5541402

    Once that's in, that option should in theory gives us "MPRF 0"-like input lag at all times. This is especially going to be useful for g-sync/freesync.
     
    Last edited: May 3, 2018
    MaxiJazz likes this.
  17. MaxiJazz

    MaxiJazz Member

    Messages:
    23
    Likes Received:
    0
    GPU:
    Geforce GTX 1070
    @RealNC it only increase lag in situations where my config can reach 144fps(144hz monitor) with v-sync on?
    So it will not work, where my fps < then my monitor's refresh rate?
    Sry for dumb questions. :D
     
  18. RealNC

    RealNC Ancient Guru

    Messages:
    4,954
    Likes Received:
    3,234
    GPU:
    4070 Ti Super
    When the GPU is maxed, then it increases input lag even if FPS < Hz. You can test it in Witcher 3 which a GPU-heavy game. With everything on Ultra, this game will probably never reach 144FPS. With MPRF 8, the lag makes in unplayable. With MPRF 1, it's fine. And with a frame limiter, it's even better (because the frame limiter prevents the GPU from maxing out.)
     
    MaxiJazz likes this.
  19. Unwinder

    Unwinder Ancient Guru Staff Member

    Messages:
    17,127
    Likes Received:
    6,691
    "CPU-prepared frames" is a correct definition, and pre-rendered frames should not be treated as the frames that have been pre-rendered already but kept in a frame buffer queue to be displayed later. The main idea behind pre-rendering is to allow CPU to submit frames to DirectX runtimes / display driver a bit faster than GPU is able to render them. Each pre-rendered frame is not a presentable pre-rendered framebuffer, each pre-rendered frame is a command buffer submitted by CPU (i.e. complete set of rendering instructions required to render new frame when GPU finish processing current frame(s)). That's exactly where input lag is coming from.
     
    BlindBison, Mda400 and RealNC like this.
  20. RealNC

    RealNC Ancient Guru

    Messages:
    4,954
    Likes Received:
    3,234
    GPU:
    4070 Ti Super
    @Unwinder

    Thanks for clearing that up. It sounds like that even with MPRF 1, rendering is still not synchronized to the CPU. 1 prepared frame is submitted while the GPU is still rendering the previous frame. Frame limiting the game will effectively force rendering to be synchronous? At least if the game doesn't use different threads for presenting and preparing frames? (At least that would be a good explanation for the latency reduction you get when capping the frame rate.)
     
    Last edited: May 3, 2018

Share This Page