at high GPU usage, is it better to set an in-game FPS cap or to use nvidia ultra low latency mode?

[chaps._]

TLDR: in GPU bound scenarios (particularly those with a high framerate like 130-144 fps) which option provides the lowest input lag reduction, in-game fps cap or Nvidia ultra-low latency mode (NULLM)?

Hey, I'm sorry if this has been discussed previously, but I haven't found an answer to this specific question. my goal is to get a configuration that gives me a tear-free experience with the lowest input lag possible, and based on the G-sync 101 articles and several youtube videos I've come to the following conclusions:

1. Turn G-sync and V-sync on and use the in-game fps limiter to cap the framerate at least 3 fps under the monitor's G-sync range (in my case it would be 141hz since my monitor runs at 144hz).

2. Although Null causes a slight input lag increase in non-GPU bound scenarios, it's not that big or noticeable, so leaving it on won't do harm.

now the tricky part comes with GPU-bound scenarios, and I'm wondering if NULL (ultra is the only option available in my HP OMEN 15 for some reason) is better than an in-game fps limiter or vice-versa. I have 2 examples: fall guys and days gone. for the 1st game, I have a high GPU usage and high fps (130-140 fps), and for days gone I have a high GPU usage and lower fps (85-95 fps). So in the case of fall guys, would an in-game framerate cap of 140 have lower input lag than using NULL? The only thing I don't like about null is that it sets the cap a little lower than I would like (138) and you can't control how big the limit is.

[jorimt]

A manual FPS limit will only prevent render queue latency if it's the limiting factor. I.E. if the framerate falls below the limit at any point due to maxed GPU usage, render queue latency will occur regardless.

As such, when using a manual FPS limit to prevent render queue latency, you have to ensure your set limit is slightly below your system's lowest achievable average framerate in the given game. So if your lowest average framerate in Fall Guys is 130, then you'd limit the framerate to, say, 127 frames (as to prevent maxed GPU usage). Same goes for Days Gone; if lowest achievable average is 85, then you'd limit to ~80 FPS, etc.

As for LLM "Ultra," the 138 FPS limit you're seeing at 144Hz is to keep the framerate within the refresh rate when G-SYNC is active. It is not in place to reduce render queue latency, it's to ensure the framerate remains within the G-SYNC range.

Instead, LLM "Ultra" (with or without G-SYNC enabled) attempts to reduce render queue latency by timing delivery of new frames "just-in-time," which can, at best, reduce render queue latency in GPU-bound scenarios by 1 to 1 1/2 frame, and at worst, cause stutter.

Finally, just a heads up that LLM On/Ultra isn't supported in DX12 or Vulkan at all, and it doesn't work in every DX11 or under game either, so it's not the most reliable method for avoiding render queue latency due to maxed GPU usage.

[imprecise]

As jorimt points out, there are shortcomings with both methods. The best option will vary from game to game and person to person. I would recommend turning gsync on, vsync off, and low latency mode to ultra. If you're experiencing problems on those settings, then I would definitely try some other things (too long to list). I made a short list here (esports optimization, not tear-free optimization) viewtopic.php?f=10&t=10724

[chaps._]

A manual FPS limit will only prevent render queue latency if it's the limiting factor. I.E. if the framerate falls below the limit at any point due to maxed GPU usage, render queue latency will occur regardless.

As such, when using a manual FPS limit to prevent render queue latency, you have to ensure your set limit is slightly below your system's lowest achievable average framerate in the given game. So if your lowest average framerate in Fall Guys is 130, then you'd limit the framerate to, say, 127 frames (as to prevent maxed GPU usage). Same goes for Days Gone; if lowest achievable average is 85, then you'd limit to ~80 FPS, etc.

As for LLM "Ultra," the 138 FPS limit you're seeing at 144Hz is to keep the framerate within the refresh rate when G-SYNC is active. It is not in place to reduce render queue latency, it's to ensure the framerate remains within the G-SYNC range.

Instead, LLM "Ultra" (with or without G-SYNC enabled) attempts to reduce render queue latency by timing delivery of new frames "just-in-time," which can, at best, reduce render queue latency in GPU-bound scenarios by 1 to 1 1/2 frame, and at worst, cause stutter.

Finally, just a heads up that LLM On/Ultra isn't supported in DX12 or Vulkan at all, and it doesn't work in every DX11 or under game either, so it's not the most reliable method for avoiding render queue latency due to maxed GPU usage.

Oh okay, so for what I understand an FPS cap will only reduce the input lag if my GPU is maxing out, and as such, I should cap the fps slightly under my lowest fps average. In addition to that, LLM caps the fps at 138 to keep the framerate under the G-sync range and is not meant to reduce the latency. So based on that information (and ignoring the 138 fps limit that NULL introduces) do you think it would be a better idea to just use G-sync + V-sync + NULL and not think too much about it, or would it be better to use G-sync + V-sync + per game fps cap?

[RealNC]

In addition to that, LLM caps the fps at 138 to keep the framerate under the G-sync range and is not meant to reduce the latency.

It is meant to reduce latency. Reducing latency is the only reasson to cap FPS below the g-sync ceiling.

[jorimt]

Oh okay, so for what I understand an FPS cap will only reduce the input lag if my GPU is maxing out, and as such, I should cap the fps slightly under my lowest fps average.

If using a manual FPS limit, correct.

In addition to that, LLM caps the fps at 138 to keep the framerate under the G-sync range and is not meant to reduce the latency.

The 138 FPS limit (at 144Hz) prevents sync latency by keeping the framerate within the G-SYNC range at all times, while the "just-in-time" delivery component reduces render queue latency whenever GPU usage is maxed.

I.E. two separate forms of latency address by two separate solutions via the same LLM Ultra setting.

So based on that information (and ignoring the 138 fps limit that NULL introduces) do you think it would be a better idea to just use G-sync + V-sync + NULL and not think too much about it, or would it be better to use G-sync + V-sync + per game fps cap?

Entirely up to you.

G-SYNC on + V-SYNC on is to ensure 0 tearing within the refresh rate (G-SYNC on + V-SYNC off can and will tear during larger framerate variances, even with framerates within the refresh rate). While a limiter (a minimum of 3 frames below the current physical refresh rate), regardless of method, be it in-game, Nvidia MFR, RTSS, LLM Ultra, or Reflex, should be used to prevent the framerate from exceeding the G-SYNC range.

As for LLM, again, it's game dependent, ultimately situational/preferential, and will only further reduce latency whenever the GPU usage is maxed.

Finally, if we were to rate the overall effectiveness of render queue latency reduction methods, it would be:

1. Reflex
2. Manual FPS limit
3. LLM Ultra
4. LLM On