Does Reshade Introduce Latency/Input Lag?

If yes, how much ms latency/input lag does it introduce? And does latency depend on what shaders are used? (Btw. I have a 1070 GPU)

Thanks!

FLIR wrote: If yes, how much ms latency/input lag does it introduce? And does latency depend on what shaders are used? (Btw. I have a 1070 GPU)

Thanks!

It does, because it takes longer to process the image. With a 1070 though, there aren't many shaders that will dent the performance in a noticeable way, unless you stack them all, or run at 144hz or something.

Measure its impact on fps, that should give an idea.
eg. if it reduces your fps from 100 to 90, then input latency may be increasing from 10ms to 11.1ms

I've been doing some performance testing and found some really big fps gains if I

1. stack all my shaders into one shader file (I'm using custom.h)
2. disable RFX_InitialStorage and RFX_DepthBufferCalc in common.cfg (if your shaders don't need them)
3. disable the reshade framework with the toggle key. the framework gets turned off resulting in ~5% gain and the shader is still in effect

144hz should not affect input lag in a negative way, actually it should help it for example vsync latency is reduced because the wait interval to the next refresh is lower (7ms instead of 16.7ms)

we can do this in Reshade 3 or just previews?
if 3 ..how to make cusome?

He's talking about a REALLY old version of ReShade. Either 1.x or 0.x. AFAIK, ReShade 3 doesn't work the same way, and I don't think you will get a performance boost past performance mode.

Also, disabling the framework means depth and original color are no longer updated. That does mean a slight performance increase (negligible on a 1070), but it will break a lot of effects.

144Hz does not impact input lag, only makes it more noticeable, since the time window is much shorter for it to render before the monitor displays, meaning potentially more dropped frames, which, in a way, is a form of input lag. It will still have less lag than a 60hz monitor as long as the framerate is above 60.

ShoterXX wrote: He's talking about a REALLY old version of ReShade. Either 1.x or 0.x.

2.0.3.1120. But I use all the versions in case I encounter a game that doesn't play nice with a particular version.

ShoterXX wrote: That does mean a slight performance increase (negligible on a 1070)

I'm using a 1070 + 4790k and it's not negligible! I'm using frafstestpattern and various games to test performance and it's a difference of up to 10% on a 1070. I hate to say it but reshade is not very well optimised (hopefully this improved in v3 - would give me a good reason to start using it ). Every time I add a new "technique" or "pass" it seems to add a ~5% overhead, and I found there are huge gains to be made for putting everything in one pass/technique. Also don't think that just because you toggled the reshade framework off that it's equivalent to not using reshade at all, because it isn't. The framework itself seems to have a 5% overhead, and can be off while the shader is still on. If only there was a way to launch in this "framework off, but shader on" state so I wouldn't have to toggle it off every time I load a game (I of course tried RFX_Start_Enabled 0 but that starts it completely disabled)

pneumatic wrote:

ShoterXX wrote: He's talking about a REALLY old version of ReShade. Either 1.x or 0.x.

2.0.3.1120. But I use all the versions in case I encounter a game that doesn't play nice with a particular version.

No, I stand correct. "RFX_InitialStorage" and "RFX_DepthBufferCalc" refer to the 1.x and earlier Framework. They do not exist in ReShade from 2.0.0 and beyond.
Even if you did update the .dll, which I don't think is the case, you are still using the outdated framework.

pneumatic wrote:

ShoterXX wrote: That does mean a slight performance increase (negligible on a 1070)

I'm using a 1070 + 4790k and it's not negligible! I'm using frafstestpattern and various games to test performance and it's a difference of up to 10% on a 1070. I hate to say it but reshade is not very well optimised (hopefully this improved in v3 - would give me a good reason to start using it ). Every time I add a new "technique" or "pass" it seems to add a ~5% overhead, and I found there are huge gains to be made for putting everything in one pass/technique. Also don't think that just because you toggled the reshade framework off that it's equivalent to not using reshade at all, because it isn't. The framework itself seems to have a 5% overhead, and can be off while the shader is still on. If only there was a way to launch in this "framework off, but shader on" state so I wouldn't have to toggle it off every time I load a game (I of course tried RFX_Start_Enabled 0 but that starts it completely disabled)

Never said ReShade without the framework didn't have a hit on performance. This was noticeable on my laptop, but I can't measure it in my current desktop.
Also, up to 10% from what exactly? If you're running a simple test at around 2000 FPS, any load at all will hit like a truck. And are you sure the overhead is not CPU-bound or something (though I can't really tell either, and it shouldn't make much sense regardless)?

ShoterXX wrote: I'm using a 1070 + 4790k and it's not negligible! I'm using frafstestpattern and various games to test performance and it's a difference of up to 10% on a 1070. I hate to say it but reshade is not very well optimised (hopefully this improved in v3 - would give me a good reason to start using it ). Every time I add a new "technique" or "pass" it seems to add a ~5% overhead, and I found there are huge gains to be made for putting everything in one pass/technique. Also don't think that just because you toggled the reshade framework off that it's equivalent to not using reshade at all, because it isn't. The framework itself seems to have a 5% overhead, and can be off while the shader is still on. If only there was a way to launch in this "framework off, but shader on" state so I wouldn't have to toggle it off every time I load a game (I of course tried RFX_Start_Enabled 0 but that starts it completely disabled)

This is all moot unless you start testing with 3.0, prior versions are unsupported and 3.0 is leagues above previous versions in both functionality and performance.

Martigen wrote: [strike]

ShoterXX wrote:

[/strike]

PS: it wasn't me writing that

ShoterXX wrote: "RFX_InitialStorage" and "RFX_DepthBufferCalc" refer to the 1.x and earlier Framework. They do not exist in ReShade from 2.0.0 and beyond.

I have checked it again just now and am seeing a 4% difference in gpu load with initialstorage and depthbuffer on/off at 144fps with 2.0.3.1120. At 60fps it's only 2% though. It also varies depending on the particular scene that's being rendered, that's why I use frafstestpattern to benchmark it with RTSS overlay. Turning the framework off with toggle key but keeping the shader on is worth another 5%so all up about 9% gain by turning all those things off, plus another 3-4% from putting all shaders into one pass. v3 suffers some compatibility issues and I need to automate reshade config files manually for my application purpose so v3 just isn't viable for my use at the moment.

Yeah a lot of people seem to be running a mix of 2.x and 3.x versions of ReShade for compatibility reasons either with software or with the actual shaders and existing presets.

3.0.8 should be pretty fixed up now although there's some additional tweaks for OpenGL on Github that aren't in the existing release version yet.
(But that might be primarily for AMD and how they handle the API's specifications and conforming to those standards.)

Though yeah not every 2.0 shader was updated to be compatible with 3.0 and some were replaced for other variants and all older presets are probably not going to be 3.0 compatible without a lot of work unless the authors for these were to come back and update them so while the 3.0 release likely has a lot of improvements compatibility is going to be a issue for quite some time.

I tried reading the documentation a bit for 3.0 just to see what it would be like but yeah there's no way I would be able to convert a 2.x shader for 3.x so unless you have some understanding and knowledge about shader editing and ReShade's functions already it's probably not very easy for your average user to undertake something like that thus all the requests on these forums for updating various 2.x shaders, of which there's a fair number now already.

And software wise well some games are just going to be difficult too (And not just depth buffer issues.) and conflicts with other software is also a possibility, not sure how much time Crosire currently has to look into this at the moment either as the primary author of the ReShade injector code though open sourcing ReShade's code base has helped going by the number of forks on Github though it's a slow process but there's been a few code submissions and improvements already.
(In part it's probably because it's a pretty complicated piece of software doing a lot of complex operations for what it offers.)

Not really sure how much the display drivers factor into this either, AMD does things a bit differently for OpenGL thus the current change on Github fixing that issue but there's probably other problem areas too.

so why lag if reshade says 60fps but lot of miliseconds input lag?

I believe the term input lag here must be used as the delaying of the frames, rather than the FPS.

For example, in a V-Sync on case, a game gives 85ms input lag without Reshade, and 120ms with Reshade on (both being 60FPS), than we can say Reshade introduces input lag.

As for the comments and from experience, I can say Reshade doesn't introduces input lag as long as the fps is same between on and off. However, if reshade drops your FPS by half, then performance dependent input lag increases slightly.