Does the Nvidia Inspector FPS Limiter Allow Prerendered Frames? (Max Prerendered Frames NCP Setting)

Discussion in 'Videocards - NVIDIA GeForce' started by EerieEgg, Jul 31, 2019.

  1. EerieEgg

    EerieEgg Master Guru

    Messages:
    225
    Likes Received:
    18
    GPU:
    RTX 2080 Super
    Hi there guys,

    I've read online and here in the forums that the way FPS limiters generally break down is:

    1) In-Game / In-Engine limiters -- these tend to be "Best" if available -- at least with respect to input lag, but their frame pacing can be a bit wonky and it can vary per game as I understand it.

    2) Rivatuner (RTSS) -- this tends to have good framepacing and less input lag than the Nvidia Inspector FPS Limiter, though more input lag when compared with the in-engine / in-game limiters (usually).

    I'd heard previously that RTSS does not allow the CPU to prerender frames while it is engaged and you are reaching the set FPS cap. This may go some way to explaining why it has lower input lag when compared to the Nvidia Inspector limiter and that's primarily what I'm inquiring about here in this thread.

    3) Nvidia Inspector FPS limiter ("Default" or V1 -- I'm uncertain of the differences between the two, but I expect overall "Default" is the preferred/recommended option due to it being the default -- correct me if I'm wrong there, I'd love to learn more about the difference between the two and how they work).

    From what I've read, this limiter usually has more input lag when compared with RTSS and in-game limiters, but -- does the Nvidia Inspector FPS Limiter allow the user's "Max Pre Rendered Frames" setting to be used? / Does it allow the CPU to prerender frames as it would be permitted to do as if the framerate was uncapped?

    For example, if the user has a MPRF (flip queue) setting of 3 forced in the driver and they cap their FPS with RTSS, my understanding (which could be wrong so correct me if that's the case) is that while reaching the set fps cap (while RTSS's fps limit is engaged), the CPU will be prevented from preparing more frames. Is this also the case with the Nvidia Inspector FPS limiter(s)?

    If not -- if NI's limiter does allow the CPU to prerender frames than this could be a pro and a con as well as go someway towards explaining why the limiter usually has more input lag when its been tested in the past.

    The reason why this matters is that I often see a small "stutter" on my setup whenever RTSS dips beneath its set framerate limit -- for example, if I cap at 141 in DOOM 2016, then my fps wavers in a heavy encounter and my fps dips to 137, then I often seem to get a small hitch or stutter.

    This does not seem to occur if I "uncap" my fps and do not set a limit nor does it seem to occur if I use the Nvidia Inspector FPS limiter so (where my MPRF value is currently set to 2) -- going off the above, my best "guess" then is that this is because the Nvidia Inspector Limiter lets the CPU prerender frames as set in the user's control panel to help mitigate stutters like these, but I'm speculating (will do more tests).

    Now, of course I could be way off on all this, but I wanted to ask because this seems like a fairly important distinction between the limiters depending on what the answer to this is.

    Thank you for your help and time, I appreciate it.
     
    Last edited: Jul 31, 2019
  2. EerieEgg

    EerieEgg Master Guru

    Messages:
    225
    Likes Received:
    18
    GPU:
    RTX 2080 Super
    @Unwinder Regarding this topic, if you get a chance to take a look, does RTSS allow the CPU to prerender frames while the RTSS cap is engaged? I'd heard it does not here on the forums, but it would be helpful to confirm this since it could explain the difference I'm seeing between the RTSS limiter and the Inspector limiter as described above. Thanks
     
    Last edited: Jul 31, 2019
  3. A M D BugBear

    A M D BugBear Ancient Guru

    Messages:
    3,055
    Likes Received:
    284
    GPU:
    4 GTX 970-Quad Sli
    I do know that throughout my testing under 4-way sli, max prerendered frames may help with the fps fluctuations/Sli consistency, not 100% it will help, alot has to do with the fine tuning of the bits, even then, don't expect 100% results under sli mode.

    It may increase or decrease overall performance, based from my experience messing with this particular setting.

    I normally keep it under 4 under 4-way sli, if its single gpu, I set it to 1.

    Another very important factor here, to ensure the highest overall fps, always set vsync to off, especially in benchmark programs.

    I normally only use multi-gpu setups.
     
    Last edited: Jul 31, 2019
  4. EerieEgg

    EerieEgg Master Guru

    Messages:
    225
    Likes Received:
    18
    GPU:
    RTX 2080 Super
    @A M D BugBear Thanks, that's good to know -- for this, I'm primarily wondering about whether or not different fps limiters prevent or allow the the CPU to "Prerender" frames though -- so, whether or not RTSS or Nvidia Inspector's limiters will allow the user's setting for the Flip Queue / Max Prerendered Frames setting to work while engaged/reaching the limited fps value. I'd previously heard that RTSS does not allow the CPU to prerender frames, but I've got no idea if Inspector's limiter does allow it (or in-game limiters for that matter) so I wanted to make this thread to ask about it. For SLI, if I remember correctly, MPRF / Flip Queue = 1 doesn't do anything since SLI requires a certain number of pre-rendered frames iirc. Of course correct me if I'm wrong there. Thanks for your reply.
     

  5. A M D BugBear

    A M D BugBear Ancient Guru

    Messages:
    3,055
    Likes Received:
    284
    GPU:
    4 GTX 970-Quad Sli
    Just to let you know, I also messed with the fps limiter within nvidia inspector, and yes it does work but I mostly try to set it off so I can get the highest possible fps.

    I always have vsync turned off, regardless of the tearing, Especially when I am doing a very intense project like 4-way setup, you want to make sure you have it off at all times, and yes it makes a big difference at times, depending on game and situation within a particular game.

    Very good topic you brought up, thanks a bunch. I don't usually mess with the max pre-rendered frame but occasionally I do, and on some games, I do see a difference in overall fps performance and or the stuttering in general, it may help tame the stuttering alot or by a lil bit, all depends on the game and alot of it is how you tune the darn bits but then again it may not help at all, it may help in some games but then again do not expect it to help 100% of the time.

    When you get a chance, take a look at my thread:

    https://forums.guru3d.com/threads/my-experience-with-4-way-sli-thus-far.425674/

    Nice avatar my friend, reminds me the one of the monsters in D&D: Eye of the beholder, lol.. :rolleyes:
     
    EerieEgg likes this.
  6. EerieEgg

    EerieEgg Master Guru

    Messages:
    225
    Likes Received:
    18
    GPU:
    RTX 2080 Super
    Thanks for the link, that's really interesting. Will look into that after work. 4-way SLI sounds very ambitious. Yes, I hear you -- I've read a lot recently regarding the Flip Queue / MPRF, and -- provided I'm understanding everything correctly (I may not be of course), the flip queue size shouldn't cause any issues as long as you're GPU bound.

    The reason seems to be because the flip queue purpose is to prevent the GPU from being idle and waiting on the CPU if/when the CPU lags behind, but if the CPU has the frame(s) prepared before the GPU (if you're GPU bound), then there shouldn't be a problem caused (normally) by MPRF = 1 provided I'm understanding everything correctly.

    From what I've read, upping MPRF / Flip Queue helps when your CPU is worse than your GPU or when you're often CPU bound since then when once the GPU has rendered the frame, it has to wait for the CPU to finish the next one and can't work continuously -- a queue can apparently help with that since if the CPU gets behind you have some buffer time where the GPU will keep getting fed frames from the CPU's queue and when the CPU does manage to catch up and get some overhead it can refill up the queue.

    That's my understanding at least -- for me, 1 or perhaps 2 are about the highest I can tolerate though and 1 shouldn't be any problem provided you're GPU bound going off my current understanding since -- CPU prepares frame and passes it off to GPU -- once that frame has been passed to the GPU, the CPU can start working on the next frame. The only problem comes into play I expect if the GPU finishes its work on that frame before the CPU can finish its work on the next frame in which case a queue of frames could help.

    Anyway, of course all of this is "provided my understanding of how this works" is correct, but that's what I've pieced together -- it could be that what I just described is MPRF = 2 behavior since I'm not sure if the CPU can immediately start preparing the next frame once its passed the current one off to the GPU -- it could be that the CPU doesn't even begin work on the next frame until the GPU has totally finished rendering out the frame and if that's the case, then perhaps flip queue 2 is what you want since then the CPU can start work on the next frame immediately once its passed on the current one to the GPU, but there's too many unknowns regarding all of this atm.

    Thanks :) It's some art for the Behelit from the Berserk manga. Your profile pic is pretty sweet yourself -- it's certainly identifiable and a fun one xD have had a lotta fun with D&D over the years myself.
     
    Last edited: Jul 31, 2019

Share This Page