Optimizing performance using reshade

I just started using ReShade and really like the features it brings to the gameplay experience. However, I am having some performance issues when using some heavy filters. Can anyone help me with tuning or how to use ReShade? Tips on shader selection, settings, or any other experience would be greatly appreciated!

Thanks everyone so much!

manuellwhite wrote:

I just started using ReShade and really like the features it brings to the gameplay experience. However, I am having some performance issues when using some heavy filters. Can anyone help me with tuning or how to use ReShade? Tips on shader selection, settings, or any other experience would be greatly appreciated!
among us
Thanks everyone so much!
 

I'm still looking forward to any shader selection guides, settings, or any other experience that might help me

This might be quite the difficult question to answer. There are many, many shaders out there in the wild, as well as presets that can utilize dozens of shaders from multiple sources. Essentially what you're asking for is what everyone wants: more pretty, less performance hit. This is mostly on you - you need to get the shaders and get to tinkering. Just like when you install a game and dive into the options menu and start experimenting with graphics settings to find the best balance for visuals and performance, you'll be doing the same thing in ReShade. Here's some guidance I can offer, though I'm sure others here that are much smarter can offer more.

We'll start with the important part: what are you trying to do with ReShade? I like to tackle my ReShade stacks based on what elements the various shaders present visually or functionally. We'll go with a "full stack" of shaders that offers features for color grading, image enhancement, lighting enhancement, and film effects. The order of the shaders/techniques can affect the final frame performance and visuals. Here is what a list of that stack might look, using pseudo/example names (that is, these aren't real shaders to download):

1. Utilities (source data other shaders use, like motion vectors or normals)
2. Color baseline (color transforms, normalization, etc)
3. Preliminary enhancement (fast sharpen technique, debanding, etc)
4. Color grading (game photographer fun)
5. Lighting features (ambient occlusion, global illumination, etc)
6. Core enhancement (advanced sharpening, noise reduction, etc)
7. Film effects (noise, vignette, chromatic aberration, etc)
8. Final color grading (fine tuning)

Each of those stages in the stack serves a purpose, and the order matters. There are a plethora of reasons thinks can go wonky or otherwise have an undesirable end result visually or performance wise. Also making sure shaders aren't doubling up on work is important. Take a very simple example: having an animated noise film effect before a sharpening technique can go south really quick. The sharpening functions might struggle to figure out where edges are, because all those pesky moving pixels blotted over the whole screen is overwhelming.

Many shader libraries have helpful and important utility functions, such AO and global illumination shaders needing access to advanced depth maps, motion vectors, etc. You'll typically see the documentation on those shader libraries explicitly stating their utility shaders need to be at the top in shader ordering before their other shaders. Now you may run into a case where you have multiple shader libraries from different creators, and they may both have a utility library (for example, 2 libraries that both have normal data that their shaders use). Keep an eye on this element, since it's the first part of your stack and sets the pace concerning performance. If you have 2 shaders doing some heavy calculations on normals, well that's already an unnecessary hit to performance.

If you're doing any sort of color grading, scrutinize the performance hit from these shaders. I've tested dozens and dozens of colorist shaders, and now I've taken to writing my own. There is no reason color space transforms, tonemapping, and 3-way lift/gamma/gain tweaks should be sucking up 6ms. My own color grading suite has a footprint of ~0.07ms with all the bells and whistles and gives me full control of color, bordering professional level color grading features. Keep a tight grip when it comes to color grading, there are plenty of shaders out there that do a great job with minimal performance hit. There are just as many that have great marketing and screenshots to get you hooked, but they have horrible approaches and optimization. Though if you're just taking still shots and not looking for playable frame rates, this wouldn't be an issue.

Lighting features is where your biggest performance hit is likely to occur. Again, there are many shaders out there that tackle lighting features such as ambient occlusion and global illumination, each with their own approaches, visual quality/style, and performance impacts. Outside of the baseline performance each shader may have, the most common settings you are looking to tweak for the quality/performance balance are the amount of steps, resolution (some shaders can calculate at full/half/quarter resolution), and complexity (some shaders have fast/moderate/advanced algorithm options).

The same logic applies to various film effects. I've slapped on animate film noise shaders that simply obliterates my frame rates, with only the sharpest of eyes being able to see the quality difference between those and noise shaders that have no impact at all. Again, if you're taking stills, probably a non-issue.

My advice is to just get in there and experiment. Start by identifying what you're after, grab several shaders that tackle each element in your stack, and zero in on the best shader(s) for that element. Do isolation testing, where you only have shaders related to the given element enabled. Doing color grading and adding some ambient occlusion? Start with only color grading, and select the one that meets your needs functionally, visually, and has good performance. Then move on to lighting shaders, only having the shaders related to ambient occlusion enabled, and test and tweak until you have your AO shader candidate. Then enable both color grading and lighting shaders, do more tweaking and testing to make sure they're compatible.

I'm sure someone could just drop a link and say "here, us this preset, it's the best" and it could very well work for you, for every game and situation you might run in to. But with the above basic approach, you can develop your own stacks/presets and be a little better equipped to have total control. It's easy to go overkill and have tons of shaders going, but at the end of the day if you're looking for playable frame rates and a visual upgrade... Less is generally more. With my own set up I've gotten used to, sometimes I forget how a game looks with ReShade disabled, and when toggling them on and off, the difference is there for sure. But the actual sliders and values changed are very small adjustments. Try and make use of before/after type tools, look away every now and then, etc. The mind plays tricks on you, so being able to keep your eyes sharp helps a lot. Also have someone else look at before and after comparisons. External input/feedback goes a long way as well.

Late to the party, but just in case someone else reads this.

1) use less/different shaders
Some shaders do basically the same thing but faster and maybe not as well or slightly differently -- film grains come to mind.  Others have more effects already merged inside it for performance gains if you were already using those effects as different shaders.

2) rewrite them yourself to be more performant
This usually means being clever about your specific reason for using a particular set of shaders together -- not really about being more clever than the author of the shader because that person knows their shader best.  A practical example off the top of my head: say you're using a comic outline shader but you want to antialiase the outline and it doesn't have its own antialiasing feature.  You could run SMAA or whatever afterwards, but you really only need to antialias the outline.  You can rip the needed code from SMAA and put it in the comic outline shader and optimize it so it only needs to compare purely black and white pixels and it'd probably only need to edge hunt in like a 3 pixel radius.  Or (a more complicated example I guess) let's say you're using prod80's luma fade, but then you also want to run other shaders at the opposite time as the first -- you could just clone prod80's shader and just do it all twice, but you can get big performance gains by instead implementing in such a way that it only needs to calculate the frame luminance once for both sides of the effect.  Sometimes you gotta look at the actual compiled shader code to see how the gpu optimizes what's currently there to give you some clues what to do next because after you manually do that by hand it can lead to ideas for other easy to implement optimizations.  Understanding how if statements (branching in general) really work in pixel shaders (along with discard) -- it's different enough th1an normal cpu programming to warrant some google searches on the topic

3) You can make code arbitrarily faster if it doesn't need to be correct 
Maybe correctness doesn't matter that much in your particular scenario... easy example of that would be to just use a pixel's green channel instead of doing a real luminance calculation.  Another would be using a lower mipmap level instead of the full image -- maybe the shader works well enough at half res, which is 1/4 the number of pixels.  Or maybe your LCD panel has high enough pixel color change latency that you can flip-flop the rendering of your shader and not really tell the difference.  Or maybe a carefully selected array of points works well enough instead of doing real random samples.

4) manually merging completely different shaders together by hand
This gives the gpu more opportunities for optimization, and there are latencies in certain operations (like tapping other pixels) where it can do pure math in parallel.  You don't even need to 100% understand what the algorithm is doing, only like 90%.  Low hanging fruit would be any shaders that use the depth buffer, like for AO.  You can take a heavy reshade stack and get it down to around half gpu time by merging shaders and doing some amount of optimization by hand, but it depends and it takes time.

5) Rip parts out into their own shader to share a texture between various shaders
Reshade already does this for for you for the depth buffer, but nothing's stopping you from implementing it yourself for other shared textures... like let's say more than one shader is calculating the  average luminance of the scene -- just rip that out into its own shader and have it be a shared texture for the other shaders.

6) reduce your expectations
Do you really need to play a single player game at 120 fps?  Definitely not.  Do you really plan to play with a DoF effect?  Probably not.  Do you really need run some heavy cinematic effect  when a simple LUT or S-Curve will do?  Probably not.  Do you really need to run a sharpener when you could just use SMAA instead of FXAA?  Nopes.  Some shader effect categories (not knocking on specific shaders, I'm talking the entire category of the-thing-they're-trying-to-do) are basically just bad, even if you really wanted to use them -- because they can't be implemented properly without more information that the game isn't providing.

2-5 takes time.  You can keep pumping more and more time into it for some performance gains, but at some point you gotta call it done and move on with life.