Fast (approximate?) SMAA

More
3 months 2 weeks ago #1 by lordbean
Fast (approximate?) SMAA was created by lordbean
I've done a bit of work using (and adding) pre-processor defines to strip SMAA down to its bare minimum functional level (I call it Fast SMAA ). This shader will give you basic Color or Luma detection SMAA effect and still includes corner detection (disabling it had a negligible impact on performance and a large loss of image fidelity). Diagonal detection and all depth buffer-related features are disabled by the pre-processor definites, which means this shader is a 3-pass routine instead of 4. I measured the performance of this shader using the same edge detection threshold and number of horizontal steps as the full enhanced shader (the enhanced shader had its diagonal steps set to 1) and have generally found the pared-back shader completes in roughly half the GPU time (on my system, FSMAA averages 0.6ms per frame and full SMAA averages 1.3ms per frame). This is primarily targeted at multiplayer games in which ReShade injection is permitted (since depth buffer access is disabled in multiplayer), and at high-resolution usage (1440p or 2160p) where an aggressive anti-aliasing routine is not required due to the high pixel count. There is no new or changed code in the shader as compared to enhanced SMAA; all I have done is add pre-processor definitions and some logical checks against them to snip out sections of the shader.

No screenshots included because it's SMAA - I expect people generally know what it looks like. It just runs faster.
The following user(s) said Thank You: mbah.primbon

Please Log in or Create an account to join the conversation.

More
3 months 2 weeks ago #2 by lordbean
Replied by lordbean on topic Fast (approximate?) SMAA
My edit time-out on the original post has expired, so here's a reply with a github link to the shader. That seems to be how everyone else is doing things.
github.com/lordbean-git/FSMAA/blob/main/FSMAA.fx
I've literally just set up an account on github and have never used it before, so I'm sure I've probably done something wrong somewhere. If anyone happens to notice can they please point it out to me? Thanks in advance.

Please Log in or Create an account to join the conversation.

More
3 months 1 week ago #3 by mbah.primbon
Replied by mbah.primbon on topic Fast (approximate?) SMAA
You did a good work there mate, I already tested it on my system and it runs even faster than default FXAA
The following user(s) said Thank You: lordbean

Please Log in or Create an account to join the conversation.

More
3 months 1 week ago #4 by lordbean
Replied by lordbean on topic Fast (approximate?) SMAA
I wondered if it might actually be doing that - my testing showed it wasn't using all that much more GPU time than a FidelityFX-style CAS sharpen pass, which is a really light routine. Didn't want to make any claims without testing them though (which I didn't).

Please Log in or Create an account to join the conversation.

More
3 months 5 days ago #5 by canceralp
Replied by canceralp on topic Fast (approximate?) SMAA
I'm interested in this however I wonder, would removing diagonal detection negatively affect anti-aliasing quality? Because that's one of the strengths of SMAA over FXAA.

Please Log in or Create an account to join the conversation.

More
3 months 4 days ago #6 by Tojkar
Replied by Tojkar on topic Fast (approximate?) SMAA
So you're essentially asking: "Would a removal of a quality improving feature decrease the quality" or in simpler term: "Would a removal of the red colour remove the red colour".

So yeah..of course it will. The removal of the red colour will remove the red colour.
The following user(s) said Thank You: canceralp

Please Log in or Create an account to join the conversation.

More
3 months 4 days ago #7 by brussell
Replied by brussell on topic Fast (approximate?) SMAA
Well, canceralp has a point in asking such a question. The op strips an essential feature of the shader and just closes the thread with "No screenshots included because it's SMAA - I expect people generally know what it looks like" ... Ehm, if it looks the same, why did the creators implement in in the first place?
The post needs some detailed comparison screenshots of different scenes with fps measurements to make it convincing.
 
The following user(s) said Thank You: canceralp

Please Log in or Create an account to join the conversation.

More
3 months 4 days ago - 3 months 4 days ago #8 by lordbean
Replied by lordbean on topic Fast (approximate?) SMAA
It's pretty easy to test side by side for yourself. Use the debug feature "View Weights" in either routine (full SMAA or my edited one) to see where the differences are in how the effect is being applied to the scene. ReShade's Statistics tab will tell you all you need to know about how they perform relative to each other. Just make sure you aren't running both SMAA and FSMAA at the same time when you do your comparisons for debug outs and frame times - you're passing the output of one as the input of the other if you do that.

Edit: performance differences will also be relative to the system configuration and game that is being tested on. Since SMAA spends nearly all of its execution budget in the GPU shaders, a title that is being limited by your CPU will likely show no difference in the game's actual frame-rate between either SMAA or FSMAA. As I mentioned both above and on the github readme file however, that is not the intended usage case for my edit.

Edit 2: To address canceralp / brussel's points (which do bear some validity), the reason why I say it looks reasonably the same is because I have not fundamentally altered the way SMAA performs edge-correction blending, and hence the appearance of the shader (as defined as the places in the scene where you can see that it's running) will look practically, if not actually, identical. The long answer is that yes, disabling the diagonal detection heuristic pass does likely cause a slightly higher miss rate in overall edge detection - however my testing showed that that pass was also responsible for fully 25% of SMAA's execution time, and had a negligible overall visual impact when applied to a title running at 2K or 4K resolution. In those instances it seemed more desirable to free up the possible extra performance to the game.
Last edit: 3 months 4 days ago by lordbean.
The following user(s) said Thank You: canceralp

Please Log in or Create an account to join the conversation.

More
2 months 2 weeks ago #9 by knowom
Replied by knowom on topic Fast (approximate?) SMAA
I tested FXAA, FSMAA, and SMAA and I found FXAA was lower overhead GPU latency and like the look better. It does a better job at handling jaggies at lower overhead. It can blur a bit more aggressively though you can tweak it and minimize it quite a lot.

FSMAA vs FXAA

SMAA vs FXAA

Please Log in or Create an account to join the conversation.

More
2 months 1 week ago #10 by lordbean
Replied by lordbean on topic Fast (approximate?) SMAA
All comes down to personal taste. I don't like FXAA personally because I find it blurs details too much. To each his own :)

Please Log in or Create an account to join the conversation.