DLSS3 interpolation two-cap approach ("latency guard" in-game cap + "stutter guard" external cap)

[Chief Blur Buster]

We've gotten new information that DLSS3 interpolation creates weird behaviors with frame rate caps, but we've discovered "Best Practices".

1. In-game frame rate caps perform lowest latency with DLSS 3.

2. Few games support capping during DLSS 3 interpolation, e.g. Cyberpunk2077 and Witcher.

3. If you are having capping problems, use half-cap numbers to account for DLSS 3.0 interpolation.
- You have to do this with Cyberpunk 2077 when enabling DLSS interpolation, as that's pre-interpolation frame rate.

3. For most in-game cap with DLSS 3.0, use a frame rate less than half the max Hz.
- For example for a 120Hz OLED G-SYNC television, you want about a 55fps (110fps) in-game cap (110fps after DLSS 3 interpolation), and about a 57fps (114fps) external cap.

4. Use the two-tier cap approach to reduce latency and stutters simultaneously.
- "Latency guard" cap is the in-game cap, set slightly lower
- "Stutter guard" cap is the external cap (e.g. RTSS or Drivers or Reflex), set slightly higher but still generates post-interpolation frame rates below GSYNC Max-Hz.

The fallback cap only responsibility is to catch those rascal frametimes not successfully caught by the in-game cap (lower lag), to prevent stutters from appearing. That's why I now call them the internal "latency guard" cap and the separate external "stutter guard" cap.

6. Most of your interpolation lag disappears AND most of your stutters disappear!

It's a massively better DLSS 3.0 interpolation experience in Cyberpunk 2077 with a lot less lag. Still some, but much less laggy.

The two-tier cap approach REALLY works in some games! Not all, and you have to make sure your in-game framerate cap is less than the Reflex cap, if you're using NVIDIA Reflex, otherwise there's nasty interactions. Or just disable Reflex and use simple driver/RTSS cap, for the specific game. Experiment. It's the Wild West of frame generation.

Someday, frame generation will be lagless -- www.blurbusters.com/framegen

[Haste]

I still don't have a 4000 series to test DLSS3 FG (still hoping for prices to come down) but this is good info.

So when native frame times reach refresh rate/2 with FG on, it stutters? What's causing that behavior?


Another question (feel free to move it to another thread if its off-topic): Regarding using lag-less reprojection instead of interpolation, doesn't that entails that all the movements that aren't camera related (for example: animations) would stay at the base native rate?
Because if that's the case, then I don't really see how it's comparable. I want all the motion happening on my screen to be perfectly fluid, clear and artifact-free without exception.

Thanks

[Chief Blur Buster]

So when native frame times reach refresh rate/2 with FG on, it stutters? What's causing that behavior?

Please remember frame generation does not necessarily always fix the original game's stutter; and some in-game framerate caps don't even fully fix stutters since they are just averaging-based caps (which means it lets framerate fluctuate around the average). This can create some stutter issues, sometimes in a way that VRR can't always undo.

And sometimes certain kinds of framegen algorithms and settings will 'amplify' the original stutter unintentionally, due to variable processing loads and interactions between the game and engine. Usually DLSS will smooth things -- but I've seen situations with some engines that were very bad at framepacing, and framegen had some ..."interesting"... effects on it.

While it is possible stutter can be fixed by an intermediary by adding intentional latency (like a tiny Netflix buffer of a few milliseconds)... This is not always desirable if you don't want to pile extra latency on laggy DLSS 3 interpolation, and want to take back some very easy latency wins. If you want lower latency concurrently with smooth frame rates -- it can be useful to cap strategically.

The two-tier cap also applies to some problem software that stutters badly with in-game cap, but lags badly with RTSS cap, due to its implementation of swapchain. In this situation, creating a two-tier cap ("latency guard" in-game cap and "stutter guard" external cap) allows you to mostly have cake and eat it too. So it works in other contexts other than DLSS 3. However, this brand new DLSS 3 discovery is being shared around on some forums/Discord, and I'm sharing it here that it actually works.

To reduce confusion about the two caps, I've invented new terminologies ("stutter guard" cap and "latency guard" cap) to distinguish the two types of caps.

The low-latency-high-stutter cap (latency guard) must be set to a slightly lower threshold (~5%) than the higher-latency-low-stutter cap (stutter guard).

The % cap-below will probably vary based on your frametime volatility, but 2-3fps different is a good guideline for 120Hz VRR OLEDs + DLSS 3. Use 4-6fps different for 240Hz OLEDs.

TL;DR: Trying to fix latency AND stutter simultaneously, sometimes requires two frame rate caps

Long term, new lagless framegen algorithms can do de-stuttering, by reprojecting/warping a varying frame rate to a perpetual framerate=Hz. See the flagship diagram at www.blurbusters.com/framegen ... It would need a feed of dejittered positionals (gametime-accurate to the post-reprojection frames, aka refresh cycles during framerate=Hz). It would be even better than VRR, being able fix shader compile stutters and diskload stutters better than VRR can! However, this is not being done yet.

[Chief Blur Buster]

Some games disable their cap setting when DLSS 3.0 is enabled

Annoyingly, many games disable their frame rate cap whenever DLSS 3 interpolation is enabled. It's infuriating, since lag can spike without an in-game cap enabled -- when you're trying to tolerate INTERPOLATION, you want to minimize it lag... Hair pulling and frustrating.

I would like more game developers to allow in-game capping simultaneously with DLSS 3 interpolation.

It's not for esports, but it's damn fine for a fine session of Cyberpunk 2077 RTX ON.
Thankfully Cyberpunk 2077 lets you cap during DLSS 3.

(Jorim, any comments? Are you testing latency behaviors of DLSS 3 interpolation?)

Tomorrow, this is better for DLSS 4 or XeSS 3 or FSR 3:


(from www.blurbusters.com/framegen)

I hope AMD/Intel/NVIDIA adds this to their next version of their respective frame generation systems.

DLSS 4 or DLSS 5 maybe?

It does need API hooks for between-frame positional updates (input reads) to reprojection-timewarp the previous full-render frame to perfect positional currency, otherwise, rendertime lag can't be removed. It's a form of warping/morphing/adjusting an old framebuffer (with the help of the z-buffer and fresh input reads), in a faster way than repeat-faking 3D reality again with triangles+textures. When done with a starting frame rate of 100fps, a lot of artifacts disappear -- most of the frame generation artifacts disappear when you're amplifying 100fps to an even higher frame rate.

But that's still tomorrow's tech.

[jorimt]

(Jorim, any comments? Are you testing latency behaviors of DLSS 3 interpolation?)

I haven't planned on it as of yet, mainly because 1) DLSS3 is still pretty early in it's development, and 2) I think anyone choosing to use it must automatically accept an increase in latency (and any other quirks, issues and/or conflicts) due to its very nature and aforementioned early state, though I'm sure the latency (and other aspects) will improve over time.

Most importantly though, I'm honestly not super interested nor have the time to test it thoroughly at the moment, but I may revisit the idea at some point down the line.

For now, it can certainly be handy for casual SP games where you want to crank up the graphical settings and RT while still maintaining an effective 120+ FPS, especially if said games are more CPU-limited than not.

[Chief Blur Buster]

(Jorim, any comments? Are you testing latency behaviors of DLSS 3 interpolation?)

I haven't planned on it as of yet, mainly because 1) DLSS3 is still pretty early in it's development, and 2) I think anyone choosing to use it must automatically accept an increase in latency (and any other quirks, issues and/or conflicts) due to its very nature and aforementioned early state, though I'm sure the latency (and other aspects) will improve over time.

Most importantly though, I'm honestly not super interested nor have the time to test it thoroughly at the moment, but I may revisit the idea at some point down the line.

For now, it can certainly be handy for casual SP games where you want to crank up the graphical settings and RT while still maintaining an effective 120+ FPS, especially if said games are more CPU-limited than not.

Oh yes!

Interpolation adds TONS of lag....

But the two-cap tricks actually roughly halved interpolation lag without adding stutters -- a big reduction.

What a lot of people don't yet know is...
...frame generation is a new major motion blur reduction technology at large ratios (4x-10x).

Particularly unusually effective on 240Hz OLEDs (since 120-vs-240 is much more noticeable on OLED than LCD) -- the DLSS 3 is in the very entry level of the Wright Brothers ballpark of an eventual ULMB replacement (someday) -- able to amplify 60fps to 200fps in some situations. Maybe DLSS 5.0 is the same thing as strobe-free ULMB 3.0, who knows!

Being Blur Busters, full of fans with people who gets motion blur headaches, but want an alternative to strobe-backlight-based motion blur reduction (PWM-free), frame generation at large ratios (4x-10x) is the only way to just begin to have cake and eat it too (if lag isn't important, like playing Cyberpunk 2077 or System Shock or other game).

____

The future:

It will be a while before frame generation goes lagless -- but DLSS 3 + Interpolation is something that is occasionally a viable substitute to ULMB to some people, as long as they're OK with strobe-free PWM-free 4ms MPRTs. ULMB still reduces more blur, but I've fallen in love with brute-framerate based motion blur reduction techniques.

In fact -- earlier today, someone unexpectedly emailed me an unsolicited rudimentary 1000fps path-traced reprojection demo (DLSS=OFF!) that worked on a mere lowly RTX 3080 GPU. I'm viewing its Unity source code and running its executable. I'm working heavily behind the scenes advocating/encouraging/incubate the 1000fps 1000Hz ecosystem. Amazing how many people are starting to experiment with this now, thanks to my www.blurbusters.com/framegen ... No longer dreamer or pie-in-sky stuff anymore, as most of my spend+time is reinvested in making practical enabler technologies for PWM-free strobe-free BFI-free motion blur reduction. I'm now trying to convince him to let me release this demo later this year, after refinements.

I have two Corsair Xeneon Flex monitors (thanks to my contract work) and to push 3440x1440 RTX ON graphics at 240fps, is a stepping stone to end-of-decade 4K 1000fps 1000Hz OLED.

We're about to enter a new era this decade;

[Sptz]

3. For most in-game cap with DLSS 3.0, use a frame rate less than half the max Hz.
- For example for a 120Hz OLED G-SYNC television, you want about a 55fps (110fps) in-game cap (110fps after DLSS 3 interpolation), and about a 57fps (114fps) external cap.

4. Use the two-tier cap approach to reduce latency and stutters simultaneously.
- "Latency guard" cap is the in-game cap, set slightly lower
- "Stutter guard" cap is the external cap (e.g. RTSS or Drivers or Reflex), set slightly higher but still generates post-interpolation frame rates below GSYNC Max-Hz.

Thank you so much for this thread. Super helpful. So we're essentially capping before the actual interpolation kicks in, which makes absolute sense!

I do have a few questions, I'm playing CP2077 on my LG C9. DLSS 3 / 3.5 + FG.

When FG is enabled, Reflex is selected but greyed out, so it's forcefully used and I'm guessing the Reflex Cap is post-interpolation? So the framerate cap in CP2077 is "pre-interpolation" but Reflex "post-interpolation"?

Also, what about VSYNC? As that's also greyed out. Should VSYNC be ignored in these cases? So we're essentially not following the regular "GSYNC/VRR recommendations" when it comes to FG?

[Chief Blur Buster]

Thank you so much for this thread. Super helpful. So we're essentially capping before the actual interpolation kicks in, which makes absolute sense!

I do have a few questions, I'm playing CP2077 on my LG C9. DLSS 3 / 3.5 + FG.

When FG is enabled, Reflex is selected but greyed out, so it's forcefully used and I'm guessing the Reflex Cap is post-interpolation? So the framerate cap in CP2077 is "pre-interpolation" but Reflex "post-interpolation"?

Also, what about VSYNC? As that's also greyed out. Should VSYNC be ignored in these cases? So we're essentially not following the regular "GSYNC/VRR recommendations" when it comes to FG?

In these cases of disabled settings -- we have to let the drivers/display do its thing. FG enforces some settings in the drivers.

Ideally, GSYNC/VRR recommendations are automatically adopted internally (without further user configuring).

I haven't tried Reflex with FG, so I am not 100% sure. I think Reflex Cap is post-interpolation, if Reflex cooperates with FG.

This confusion will clear up over time, and the pre-FG / post-FG stuff may become clearer -- but this is how things roll right now to get smooth AND relatively low latency FG behaviors in Cyberpunk 2077.

Key word in "relatively low". Interpolation is laggy, but it can be almost an order of magnitude less laggy than yesteryear TV interpolation -- as a route of brute frame rate method of motion blur reduction.

[Sptz]

Thank you so much for this thread. Super helpful. So we're essentially capping before the actual interpolation kicks in, which makes absolute sense!

I do have a few questions, I'm playing CP2077 on my LG C9. DLSS 3 / 3.5 + FG.

When FG is enabled, Reflex is selected but greyed out, so it's forcefully used and I'm guessing the Reflex Cap is post-interpolation? So the framerate cap in CP2077 is "pre-interpolation" but Reflex "post-interpolation"?

Also, what about VSYNC? As that's also greyed out. Should VSYNC be ignored in these cases? So we're essentially not following the regular "GSYNC/VRR recommendations" when it comes to FG?

In these cases of disabled settings -- we have to let the drivers/display do its thing. FG enforces some settings in the drivers.

Ideally, GSYNC/VRR recommendations are automatically adopted internally (without further user configuring).

I haven't tried Reflex with FG, so I am not 100% sure. I think Reflex Cap is post-interpolation, if Reflex cooperates with FG.

This confusion will clear up over time, and the pre-FG / post-FG stuff may become clearer -- but this is how things roll right now to get smooth AND relatively low latency FG behaviors in Cyberpunk 2077.

Key word in "relatively low". Interpolation is laggy, but it can be almost an order of magnitude less laggy than yesteryear TV interpolation -- as a route of brute frame rate method of motion blur reduction.

Cyberpunk 2077 does force Reflex. When you turn on FG, Reflex is selected but greyed out or at least that's what I'm assuming it's forcing?

I initially capped it at 117 FPS (as one would normally do without FG) in NVCP and to be honest, it's running perfectly fine with 0 stuttering or lag, I guess it's because it's not reaching 120 FPS regardless of the cap. But when I tested in 1440p it was tearing quite a lot, meaning there was definitely no VSYNC being used. As that's also greyed out when FG is selected in this particular game.

[Chief Blur Buster]

But when I tested in 1440p it was tearing quite a lot, meaning there was definitely no VSYNC being used.

You could use NVIDIA Control Panel to for VSYNC ON when VRR is enabled. See if that works to hide the tearing during VRR.