Blur Busters Forums

Radeon chill would be the perfect fps limiter for my needs, except it is restricted to a max value of 300 fps. I would like to use a higher fps limit for a freesync+vsync setup at a 360hz monitor. Anyone knows a any way to set up chill so it accepts higher values? This limit has has been this way for about 7 years, but amd refuses to keep up with times.

The long story is that for CS2 the in-game frame limiter provides bad framepacing. For amd GPUs, RTSS async works excelent as an alternative, however it is disabled by Faceit Anticheat if you tick on Custorm3d Support. And without that ticked on, it causes 15ms framespikes at every 5s or so.

After testing both FRTC and Chill, the second provides excellent framepacing at a input lag cost similar to RTSS async. The only downside is that it is limited to 300 fps cap.

Thanks in advance.

cuaderno wrote: ↑

22 Sep 2025, 08:04

For amd GPUs, RTSS async works excelent as an alternative, however it is disabled by Faceit Anticheat if you tick on Custorm3d Support. And without that ticked on, it causes 15ms framespikes at every 5s or so.

After testing both FRTC and Chill, the second provides excellent framepacing at a input lag cost similar to RTSS async.

Can you give the source to both these claims?
Include a detailed list of your HW & SW components, if this is something you've come to the conclusion to based on your own testing.

In general, this image below is one of the few reliable, public data sets we have on AMD GPU's.
Source: @Calypto
Note: “Radeon Cap“ = AMD's FRTC (global frame rate limiter)

Setup a new resolution with 300Hz. It will be nearly same effect.

kyube wrote: ↑

23 Sep 2025, 08:04

cuaderno wrote: ↑

22 Sep 2025, 08:04

For amd GPUs, RTSS async works excelent as an alternative, however it is disabled by Faceit Anticheat if you tick on Custorm3d Support. And without that ticked on, it causes 15ms framespikes at every 5s or so.

After testing both FRTC and Chill, the second provides excellent framepacing at a input lag cost similar to RTSS async.

Can you give the source to both these claims?

Testing done on my own, using AMD Frame Latency Meter (flm) and frameview. Both programs showed the same delta in cap methods. Loaded de_inferno in practice mode, standing at a specific pixel on banana. I was not near max GPU load in any scenarios.

The deltas I got follow a very specific pattern to the table you posted. For reference, I just quickly redid a test and here are the flm results for each method at 300 fps.



This delta was also consitent in frameview when I tested at different spots and during actual gameplay.

I used 300 fps for control because this is the max Chill can do. At higher values, RTSS async and in-game start to have a smaller gap in input latency between them. At 400 fps or above, in-game and RTSS async are within less than 1ms from each other.

However, RTSS async and Chill are miles better when it comes to consistent framepacing, so it seems well worth the tradeoff compared to in-game cap.

For curiosity, here are capframex framepacing measurements comparing in-game and chill at 300 fps:

In-game


Chill


RTSS causing a 15ms spike was measured using capframex, but is very evident in-game too. Basically, unless you turn on Custom Direct3d support with RTSS, the spikes will be there. But with Custom Direct3d support on, Faceit AC will ignore rtss as a cap method.

Let me know if you need any more info specifically.

9800x3d
7900XTX
Windows11 latest update
CS2 2560x1440, antilag2 enabled in-game, antilag disabled in Adrenaline

cuaderno wrote: ↑

23 Sep 2025, 11:34

The data you've provided is unusual to see in these forums. Thank you for contributing valuable data.
I'm interested in why in particular you've chosen that AMD tool?
I've never came across it thus far, so I'm not aware of it's potency & how it stacks up compared to ETW-based solutions such as Nvidia's FrameView, PresentMon etc.

I usually avoid Capframex due to the overhead added by the GUI itself and resort to either FrameView or basic PresentMon data capture & plot the data in external solutions afterwards.
Could you expand the Capframex screenshot which you've provided above with these settings toggled?


What AMD driver version were you using?
Were you using DxNavi?
What was your GPUTime (GPUBusy, GPUWait) during testing?
Maybe testing a more taxing load & repeatable benchmark (CS2 benchmark map) might give a clearer picture?

This is a interesting find, I would like to see some external testing done with Chill.
Would be quite hillarious if it ends up with less latency overhead compared to AMD's global frame limiter

kyube wrote: ↑

30 Sep 2025, 11:18

I'm interested in why in particular you've chosen that AMD tool?
I've never came across it thus far, so I'm not aware of it's potency & how it stacks up compared to ETW-based solutions such as Nvidia's FrameView, PresentMon etc.

Easier to use as it registers the captured numbers quickly and I can reference them all with a single glance. I did use frameview and presentmon a bunch as I've been tracking cs2 input lag changes due to settings and updates for about a year, but I noticed that relative input lag changes between settings (ie., how much latency does MSAA 8x add compared to disabled) was consistently the same between all 3 methods, so now I streamlined my process to just use amd flm.

kyube wrote: ↑

30 Sep 2025, 11:18

What AMD driver version were you using?
Were you using DxNavi?
What was your GPUTime (GPUBusy, GPUWait) during testing?
Maybe testing a more taxing load & repeatable benchmark (CS2 benchmark map) might give a clearer picture?

This is a interesting find, I would like to see some external testing done with Chill.
Would be quite hillarious if it ends up with less latency overhead compared to AMD's global frame limiter

I did a new capture comparing again chill 300 and fps_max 300 in-game. Same spot on de_inferno. Benchmark map is annoying to use as it autochanges fps_max to 0 (and after a recent update, you can't set a bind to change it again after the map started) and because there are random 200 fps drops when a nade breaks due to scripting that are not reproduceable during games.

1920x1440, msaa 4x, anisotropic filtering 16x, HDR quality, everything else low/disabled. Vsync on, freesync on, Antilag2 enabled in-game and Antilag disabled in adrenaline.

chill 300


fps_max 300


AMD Adrenaline 25.9.1 (released Aug 25th 2025)
I did not change anything to DxNavi, so I am assuming it is enabled. Never noticed issues with it.
GPUBusy average is 2.3ms, GPUWait idk where to find

It is expected that an external frame limiter would have smoother frames than in-game limiter. At high enough frames, I think the added input latency is very small while the gains in stable frametimes are clearly huge. I tested this in many different ways as sanity checks. Very easy to notice the stuttering due to bad framepacing when getting peaked in cs2.

Chill having lower input latency than AMD global frame limiter (FRTC) at the same cap number is a given, at least on my system. Even if there are imprecisions in my number measurements as I am not using a LDAT or similar, the relative difference is high enough that is quite easy to distinguish in-game by just flicking the mouse around. The one advantage FRTC has it that it can above 300.

Hey some good news.

Version 7.3.7 of rtss has a built-in CS2 profile. If you use that profile (copy from C:\Program Files (x86)\RivaTuner Statistics Server\ProfilesTemplates to C:\Program Files (x86)\RivaTuner Statistics Server\Profiles), RTSS will no longer cause framespikes with Custom Direct 3d support set to OFF. This means I can now use RTSS as framelimiter alongside FaceitAC and it will work as intended.

cuaderno wrote: ↑

01 Oct 2025, 09:22

Easier to use as it registers the captured numbers quickly and I can reference them all with a single glance. I did use frameview and presentmon a bunch as I've been tracking cs2 input lag changes due to settings and updates for about a year, but I noticed that relative input lag changes between settings (ie., how much latency does MSAA 8x add compared to disabled) was consistently the same between all 3 methods, so now I streamlined my process to just use amd flm.

I don't quite understand what the final FLM value is supposed to represent.
There doesn't seem to be documentation in regards to it.
I'm somewhat repelled by any software AMD provides, as their track record thus far has been abysmal...
To me, it seems like a much less capable PresentMon tool...
ETW-based tooling is king for any kind of serious troubleshooting / performance evaluation attempts on Windows.

cuaderno wrote: ↑

01 Oct 2025, 09:22

I did a new capture comparing again chill 300 and fps_max 300 in-game. Same spot on de_inferno. Benchmark map is annoying to use as it autochanges fps_max to 0 (and after a recent update, you can't set a bind to change it again after the map started) and because there are random 200 fps drops when a nade breaks due to scripting that are not reproduceable during games.

1920x1440, msaa 4x, anisotropic filtering 16x, HDR quality, everything else low/disabled. Vsync on, freesync on, Antilag2 enabled in-game and Antilag disabled in adrenaline.

chill 300
...

fps_max 300
...

AMD Adrenaline 25.9.1 (released Aug 25th 2025)
I did not change anything to DxNavi, so I am assuming it is enabled. Never noticed issues with it.
GPUBusy average is 2.3ms, GPUWait idk where to find

Thank you for the wrte-up, interesting data.
Have you tried using RadeonMod or RadeonPro to find registry values which could impact the Chill limiter?

As for DXNavi, I'd say it should be mandatory for any D3D11 game (of which there are 4462, as per PcGamingWiki) on RDNA GPU's.
You can find more about it in Calypto's guide
Though, the topic of AMD GPU's is understudied with public data I came across, as barely anyone owns the GPU's and has the knowledge & willingness to do these evaluations.
E.g.: D3D, OGL & VK performance on different Windows versions & driver versions, evaluating DPC/ISR perf & general frame pacing (using different PresentMon/FrameView metrics etc.)

cuaderno wrote: ↑

01 Oct 2025, 09:22

It is expected that an external frame limiter would have smoother frames than in-game limiter. At high enough frames, I think the added input latency is very small while the gains in stable frametimes are clearly huge. I tested this in many different ways as sanity checks. Very easy to notice the stuttering due to bad framepacing when getting peaked in cs2.

I'm personally sensitive to any external limiters which add 1 frame of latency (RTSS async) or 2 frames of latency (RTSS front-edge/back-edge), hence I doubt I would be able to use either of the solutions.
NV Limiter 3 ("Max Frame Rate") is seemingly without a penalty from the public data we have and I've found it satisfactory in terms of subjective feel over subpar internal frame limiters such as in CS2.

kyube wrote: ↑

06 Oct 2025, 09:47

Thanks for the reply, it was interesting to look into dxnavi. I will look into testing it for the future.

I don't have any more info on flm, but the info displayed should be system latency. Not superconfident on its reliability, but when I was collecting data along frameview and presentmon the deltas in latency were always consistent between all 3.

Agreed the nvcp max frames is quite good, I would cerainly use that over rtss on a nvidia card for sure.