Blur Busters Forums

I'm playing a demanding game (Cyberpunk 2077) on an RTX 4070 with a i5 13600k on a 240hz monitor. Normally I use RTSS to cap frame rates but, in this case, I might not use it because Reflex helps with input lag at lower frame rates. Frame generation is also a consideration, however I don't really like the frame times/artifacts it produces presently.

My issue is that I don't want wild swings in frame rates. For instance, if I go in to the inventory menu, the fps will spike to the max refresh rate of my monitor (240fps/240hz), causing the fans in my system to ramp up. In gameplay the fps hovers around 60-80, so I would like to cap it around there. Would a NVCP cap negate the benefits of Reflex? Is it possible to have a custom limit with Reflex?

xenphor wrote: ↑

27 Aug 2023, 18:29

Would a NVCP cap negate the benefits of Reflex? Is it possible to have a custom limit with Reflex?

Not if/whenever your framerate drops below your NVCP cap (in which case Reflex would take over again), and no, you can't set a custom Reflex limit (partly because the whole reason Reflex works in the first place is it dynamically adjusts its limit to current GPU usage), but if you set a custom in-game or external FPS limit that can keep the GPU usage below 99%, you won't need Reflex anyway, since it's just a dynamic/auto version of a targeted manual FPS limit where preventing extra render queue latency in GPU-bound situations is concerned.

jorimt wrote: ↑

27 Aug 2023, 21:08

Not if/whenever your framerate drops below your NVCP cap (in which case Reflex would take over again), and no, you can't set a custom Reflex limit (partly because the whole reason Reflex works in the first place is it dynamically adjusts its limit to current GPU usage), but if you set a custom in-game or external FPS limit that can keep the GPU usage below 99%, you won't need Reflex anyway, since it's just a dynamic/auto version of a targeted manual FPS limit where preventing extra render queue latency in GPU-bound situations is concerned.

Hm I actually notice a difference in latency when the frame rate is capped with Reflex vs RTSS, even when it's the same limit. Reflex feels a bit better, especially around 40-50 range. It could be placebo I guess. The frame pacing is definitely better with RTSS.

xenphor wrote: ↑

01 Sep 2023, 13:39

Hm I actually notice a difference in latency when the frame rate is capped with Reflex vs RTSS, even when it's the same limit. Reflex feels a bit better, especially around 40-50 range. It could be placebo I guess. The frame pacing is definitely better with RTSS.

Not necessarily a placebo; the Reflex limiter is engine level, and the RTSS limiter is external. In my past testing, engine-level limiters are typically 1/2 to 1 frame lower latency than external limiters (RTSS, Nvidia Max Frame Rate, etc).

That said, yes, RTSS can tend to have steadier frame pacing (even if sometimes only by very little), because unlike most in-game limiters, it limits framerate by setting a fixed frametime target.

jorimt wrote: ↑

01 Sep 2023, 14:10

Not necessarily a placebo; the Reflex limiter is engine level, and the RTSS limiter is external. In my past testing, engine-level limiters are typically 1/2 to 1 frame lower latency than external limiters (RTSS, Nvidia Max Frame Rate, etc).

That said, yes, RTSS can tend to have steadier frame pacing (even if sometimes only by very little), because unlike most in-game limiters, it limits framerate by setting a fixed frametime target.

Okay. What's interesting is that the additional stuttering I see with Reflex enabled doesn't appear on RTSS's frametime graph.

xenphor wrote: ↑

01 Sep 2023, 15:34

Okay. What's interesting is that the additional stuttering I see with Reflex enabled doesn't appear on RTSS's frametime graph.

Not all frametime fluctuations will appear on the RTSS frametime graph.

Also, since Reflex is effectively a dynamic FPS limiter that adjusts itself based on current GPU usage, it's hypothetically possible it can introduce frametime issues in certain instances, especially if you are using it when the GPU isn't actually maxed the majority of the time.

I.E. Reflex is best used when your GPU usage is 99%+; it won't further reduce render queue latency in non-GPU-bound scenarios, at which point you're better off using an in-game or external limiter if all you're looking for is a more consistent average framerate.

jorimt wrote: ↑

01 Sep 2023, 14:10

xenphor wrote: ↑

01 Sep 2023, 13:39

Hm I actually notice a difference in latency when the frame rate is capped with Reflex vs RTSS, even when it's the same limit. Reflex feels a bit better, especially around 40-50 range. It could be placebo I guess. The frame pacing is definitely better with RTSS.

Not necessarily a placebo; the Reflex limiter is engine level, and the RTSS limiter is external. In my past testing, engine-level limiters are typically 1/2 to 1 frame lower latency than external limiters (RTSS, Nvidia Max Frame Rate, etc).

That said, yes, RTSS can tend to have steadier frame pacing (even if sometimes only by very little), because unlike most in-game limiters, it limits framerate by setting a fixed frametime target.

Frame rate caps closer to the engine tends to be lower lag but can be stutterier (being averaging-based cappers)

Frame rate caps further from the engine tends to be better for destuttering a stuttery in-game frame rate cap.

Combining Two Frame Rate Caps For Their Benefits

In extreme cases where you need to balance these two benefits better -- there's a technique where you use two frame rate caps concurrently (I now call it the "stutter guard" cap, and a "latency guard" cap).

The latency guard cap must at least be microscopically lower than the stutter guard cap.

viewtopic.php?f=2&t=12261&p=95941

It works in certain situations like
- DLSS 3 frame interpolation, or
- Stuttery emulators (internal cap), with RTSS to smooth it.

I got some compliments with the tip, including in my email where he was trying to fix RetroArch stutters (emulator = "defacto 60fps in-app cap" generally), and RTSS helped smooth those stutters. Poor framepacing from imperfect in-app averaging-based capping algorithms, from a specific emulator module. But it also applies to other stuff such as games.

Any situation where you've got a stuttery in-game cap, but you want to keep the in-game cap because it reduces latency. In many situations, the external cap has the side effect of taming the in-app cap, without re-adding latency.

In-game caps can be jittery (averagers). Mentally, if you think better in graphs, enabling an RTSS cap along the centerline of the jittery in-app cap, is like peak-shaving the RTSS frametime graph to fill in the frametime valleys, to produce a more glassfloor frametime.

Just make sure the stutter guard cap (microsecond accurate cappers like RTSS) is at least microscopically higher than an averaging-based cap, ala latency guard cap (averaging-based cappers like in-game/in-app). Experiment with that margin. The averaging-based capping algorithms tolerate it better that way.

It actually works great if done properly, with certain situations!

Chief Blur Buster wrote: ↑

01 Sep 2023, 21:28

The latency guard cap must at least be microscopically lower than the stutter guard cap.

viewtopic.php?f=2&t=12261&p=95941

It works in certain situations like
- DLSS 3 frame interpolation, or
- Stuttery emulators (internal cap), with RTSS to smooth it.

I got some compliments with the tip, including in my email where he was trying to fix RetroArch stutters (emulator = "defacto 60fps in-app cap" generally), and RTSS helped smooth those stutters.

Any situation where you've got a stuttery in-game cap, but you want to keep the in-game cap because it reduces latency. In many situations, the external cap has the side effect of taming the in-app cap, without re-adding latency.

In-game caps can be jittery (averagers). Mentally, if you think better in graphs, enabling an RTSS cap along the centerline of the jittery cap, is like peak-shaving the RTSS frametime graph to fill in the frametime valleys, to produce a more glassfloor frametime. Just make sure the stutter guard cap (microsecond accurate cappers like RTSS) is microscopically higher than an averaging-based cap, ala latency guard cap (averaging-based cappers like in-game/in-app).

Okay interesting. Unfortunately I think I'm noticing stutter in Cyberpunk even with a basic 60 fps RTSS cap with Freesync and no Reflex/Framegen enabled. I tried disabling raytracing and lowering the resolution to hopefully get a solid cap but nothing seems to help. I can get decently high frame rates (80-100) without raytracing so maybe I'm noticing CPU related stutter? Or does the game have camera related stutter with a gamepad? It is very subtle and doesn't show up on the RTSS graph.

xenphor wrote: ↑

01 Sep 2023, 21:58

Okay interesting. Unfortunately I think I'm noticing stutter in Cyberpunk even with a basic 60 fps RTSS cap with Freesync and no Reflex/Framegen enabled. I tried disabling raytracing and lowering the resolution to hopefully get a solid cap but nothing seems to help. I can get decently high frame rates (80-100) without raytracing so maybe I'm noticing CPU related stutter? Or does the game have camera related stutter with a gamepad? It is very subtle and doesn't show up on the RTSS graph.

Stutters that does not show on RTSS graph but on the display can be caused by many things. If you're using generic VRR, it is sometimes caused by the graphics/drivers/drivers inability to perfectly framepace VRR well.

This varies from monitor to monitor and from GPU to GPU, and from Windows 10 vs 11.

It's worth noting that the G-SYNC premium (native) is pretty good for that sort of thing (better GPU/driver VRR framepacing), and even so, it's not quite fully perfect.

Use Performance Mode, go fullscreen exclusive mode (not borderless/windowed), and disable all secondary monitors (multimonitor can cause jitter), and maybe CPU affinity tricks, perhaps a little Process Lasso. The drivers' VRR framepacer needs the most realtime priority it can get. Some tech such as DLSS also adds a bit of jitter, and Cyberpunk 2077 is having problems with high pollrates, so adjusting pollrates a bit (down to 500-1000Hz) can sometimes help.

Also, if you're using a gaming laptop, use a cooling pad to calm any thermal-throttling stutters.

Chief Blur Buster wrote: ↑

01 Sep 2023, 22:16

Stutters that does not show on RTSS graph but on the display can be caused by many things. If you're using generic VRR, it is sometimes caused by the graphics/drivers/drivers inability to perfectly framepace VRR well.

This varies from monitor to monitor and from GPU to GPU, and from Windows 10 vs 11.

It's worth noting that the G-SYNC premium (native) is pretty good for that sort of thing (better GPU/driver VRR framepacing), and even so, it's not quite fully perfect.

Use Performance Mode, go fullscreen exclusive mode (not borderless/windowed), and disable all secondary monitors (multimonitor can cause jitter), and maybe CPU affinity tricks, perhaps a little Process Lasso. The drivers' VRR framepacer needs the most realtime priority it can get. Some tech such as DLSS also adds a bit of jitter, and Cyberpunk 2077 is having problems with high pollrates, so adjusting pollrates a bit (down to 500-1000Hz) can sometimes help.

Also, if you're using a gaming laptop, use a cooling pad to calm any thermal-throttling stutters.

I have a 360hz Gsync native display (AW2521H) I can test with but it gives me eyestrain for some reason that I was never able to solve (even after adjusting brightness/contrast/color/gamma). The AW2521HF I'm using now with Limited Range RGB is more tolerable compared to the AW2521H adjusted to match it. Both of these monitors tend to crush blacks very badly when used with default settings at Full Range RGB which jacks up the (fake) contrast and is tiring to look at long term.

I'm on a new install of Windows 11 with a 13600k/RTX 4070/32gb 6400 DDR5 ram/Nvme drive and use fullscreen with one monitor. It would be nice if the game let you map Turn Left/Turn Right to keyboard keys so I could get some consistency when testing and eliminate any gamepad issues. At this point I probably don't want to mess with it any more other than testing a Gsync native display. Thanks for the info.