FPS Limiter

I wanted to ask for FPS limiter included in next update?
There's nothing wrong with an fps limiter. Why get 120fps and make your graphics card work harder when you can only display 60fps max anyways on most monitors. It also can bypass the need for vsync to remove screen tearing without having to endure the input lag vsync causes and fps drop. I also like to lock my fps to 30 or 40 on heavy titles that push my GPU where it flactuates wildly from 60 to 30, so I dont feel the unstable changes/spikes.

I would love to drop radeonpro's fps limiter and only use reshade with its own limiter implemented in the build, please! And also not use afterburner for same reasons on windows 10 cause radeonpro has issues running on my other pc other than win 7.



Dynamic Framerate Control
This feature also known as DFC tries to keep the rendering frame rate up to the limit you have specified in Keep up to field. By limiting the maximum frame rate, it is possible to stabilize some engines where frame rate varies a lot. For example, if a game is keeping frame rate between 50 and 80 FPS, you can set a limit of 45 FPS and enjoy a smoother experience due to stable frame latency. Even if the game is capable to deliver 60 FPS, DFC set to 60 FPS as target can also help by smoothing the frame latency, try titles like Assassin’s Creed Brotherhood or The Elder Scrolls V: Skyrim, the stuttering seem on those games with plain V-sync is removed by using DFC + V-sync on.
Keep up to XXX FPS
Specifies the target frame rate of DFC feature.

Lots of programs have some sort of FPS limiter built in, including your GPU control panel.

only thing is, that's the point of my post, isn't it ? I dont want to use lots of programs for fps limiter....
Hence why it would be wise to include it in reshade since it already has fps display, so limiter would fit right in.

Secondly, no my Amd CCC doesn't have any cap limiter.
Amd doesnt ship that, you must be used to Nvidia and don't got Amd card, else you wouldnt have said that.
Maybe Nvidia has it but not amd's CCC

V-Sync basically is a FPS limit to the monitor refresh rate. What it does is stall the CPU on the frame presentation call to prevent it from pushing more than a specific amount of frames per second to the GPU. A simple frame limiter does exactly the same except that it is not implemented by the driver, but by the application.
The input lag reduction thing is a fairy tale unless the manual FPS limiter implementation only stops render calls but keeps other processing alive at unlimited speed. You can implement the same for V-Sync too btw.
Either way, such a "good" implementation is hard to do for a generic injector like ReShade since it has no information of how the game processes input, so the only FPS limiter that could be implemented would behave exactly how V-Sync behaves.

niflexible wrote: only thing is, that's the point of my post, isn't it ? I dont want to use lots of programs for fps limiter....
Hence why it would be wise to include it in reshade since it already has fps display, so limiter would fit right in.

Secondly, no my Amd CCC doesn't have any cap limiter.
Amd doesnt ship that, you must be used to Nvidia and don't got Amd card, else you wouldnt have said that.
Maybe Nvidia has it but not amd's CCC

AMD GPUs have a limiter now. HD 5000/6000 cards technically aren't supported today if that's what you're talking about, but they DID get some kind of Crimson release... I'm fairly certain my HD 5000 APU had a framelimiter on some driver version.

Either way, going forward I don't think ReShade needs a frame limiter.

________________________________________________________

crosire wrote: V-Sync basically is a FPS limit to the monitor refresh rate. What it does is stall the CPU on the frame presentation call to prevent it from pushing more than a specific amount of frames per second to the GPU. A simple frame limiter does exactly the same except that it is not implemented by the driver, but by the application.
The input lag reduction thing is a fairy tale unless the manual FPS limiter implementation only stops render calls but keeps other processing alive at unlimited speed. You can implement the same for V-Sync too btw.
Either way, such a "good" implementation is hard to do for a generic injector like ReShade since it has no information of how the game processes input, so the only FPS limiter that could be implemented would behave exactly how V-Sync behaves.

However, if I'm understanding you, VSync isn't that simple. Lets say you're running 40 FPS on a 60hz screen. The output on the screen would be:

Frame 1, Frame 1, Frame 2, Frame 3, Frame 3, Frame 4, Frame 5, Frame 5, Frame 6, Frame 7...

7 frames in 10 refreshes.

Now, with (double buffered) VSync:

Frame 1, Frame 1, Frame 2, Frame 2, Frame 3, Frame 3, Frame 4, Frame 4, Frame 5, Frame 5...

5 frames in 10 refreshes. The problem here is that, for short periods, the GPU gets stalled because it has no buffer to draw to. The effect is even more dramatic in games with inconsistent frametimes. Triple buffering fixes that problem at the cost of a bit of input lag, but that's not an option in many games.


So what ReShade could do is what RadeonPro used to implement:

- A triple buffering toggle

- Dynamic Vsync. (Aka ReShade watches frametimes, and turns on/off Vsync as the times go over/under the refresh rate. Or, alternatively give shaders access to a Vsync toggle and frametimes so they could implement the "switch")


No idea if that's beyond the scope of this program or not (Is ReShade technically the thing drawing to the screen, eg does it get to tell the driver it wants triple buffering or VSync?). I suggested that about a year and a half ago, but I think it was too much work for the benefit then.

brucethemoose wrote: However, if I'm understanding you, VSync isn't that simple. Lets say you're running 40 FPS on a 60hz screen. The output on the screen would be:

Why would you need to limit your FPS if you aren't even hitting 60?

brucethemoose wrote: However, if I'm understanding you, VSync isn't that simple.

True, it isn't. What I was trying to explain is that V-Sync isn't a bad thing that adds "input lag" for no reason and why I don't see an advantage of a simple FPS limiter over V-Sync if you are running with more FPS than your monitor refresh rate.

FierySwordswoman wrote:

brucethemoose wrote: However, if I'm understanding you, VSync isn't that simple. Lets say you're running 40 FPS on a 60hz screen. The output on the screen would be:

Why would you need to limit your FPS if you aren't even hitting 60?

Because many games are inconsistent. I might go in cave and hit 80, but then go outside and hit 40.

A few games also need a framerate cap to run properly without VSync. Recent TES/Fallout games are notorious examples.

crosire wrote:

brucethemoose wrote: However, if I'm understanding you, VSync isn't that simple.

True, it isn't. What I was trying to explain is that V-Sync isn't a bad thing that adds "input lag" for no reason and why I don't see an advantage of a simple FPS limiter over V-Sync if you are running with more FPS than your monitor refresh rate.

True, but very few modern games consistently stay over your monitor's refresh rate.

TR has done some great writeups on that subject: techreport.com/review/25788/a-first-look...-sync-display-tech/3

If you're getting 40 average then any spikes above 60 probably aren't worth preventing.
You can also use Adaptive VSync.

FierySwordswoman wrote: If you're getting 40 average then any spikes above 60 probably aren't worth preventing.
You can also use Adaptive VSync.

The argument is kinda moot anyway, as there are plenty of 3rd party FPS limiters, and everything but Intel IGPs and ancient discrete GPUs has a built in limiter now.

Dynamic VSync is Nvidia only though. We used to be able to do it on AMD cards, then AMD (ironically) hired the RadeonPro dev and killed the program.

Feature regression like that means someone should be fired.

FierySwordswoman wrote: Feature regression like that means someone should be fired.

Technically it was never an official feature. RadeonPro was a 3rd party program.

But it should've been official. Why AMD chose to scrap RadeonPro when they hired the dev... Now THATS what someone should be fired over.