Double or Triple pass SMAA

[xHybred]

There's this old ReShade thread: https://reshade.me/forum/shader-discussion/7289-taa-quality-non-blurry-anti-aliasing-done-using-smaa-smartsharpen-presets

That makes SMAA 3x with good results. I wanted to convert this same setup into iMMERSE Anti-Aliasing since its more performance friendly as running SMAA 3x is heavy but the issue is the names for settings are different, so could someone (like Marty) explain which settings are the equalivent so I can use the same setup here?

Or perhaps this feature can be officially added into the shader (probably not, I don't mind manually doing it myself though)

[martymcmodding]

Applying SMAA multiple times is pointless, despite what the forum post claims.

SMAA doesn't naively blur the image such as FXAA would do, it detects primitive shapes, tries to guess the underlying geometry shape and then blends pixel colors to reflect the coverage of said virtual geometry as if it were infinitely super sampled.

• if an edge is above threshold, it will ideally be perfectly anti aliased by the algorithm. It won't need further processing
• if an edge is above threshold but SMAA guessed the shape wrong, it will be incorrectly antialiased. Further processing will mess it up even more
• if it's below threshold, any number of SMAA passes will ignore it. Further processing won't affect it
• if an edge is already anti aliased to some degree, the shape detection will detect the wrong shape and mess it up

The best possible AA you can get in post processing is simply using SMAA, setting the threshold sufficiently low, quality sufficiently high and that's it. You can sharpen the image afterward a tiny bit to compensate for limited pixel density but no more.

SMAA was made by the possibly smartest graphics programmer alive and there hasn't been any progress on post process AA for a decade because it just so good. This one is the only SMAA variant that improves the performance (not the algorithm) due to leveraging new programming language features that didn't exist at the time.

[xHybred]

Thank you for your response Marty.

From looking at comparison images 3x SMAA did look better to me in some regards than 1x in the game shown, so it didn't seem entirely pointless from my experience but maybe theirs something I'm not getting: https://imgsli.com/MjI4NTc0/0/5

But I do know SMAA is the best post process AA shader. What I've personally been doing is combining FXAA + SMAA for a long time now and that's been my go to solution when a games TAA is too blurry for me to handle. Apply SMAA first since it's more intelligent then FXAA after that's more aggressive/less intelligent to get whatever SMAA didn't.

What I'm wondering now is if combining FXAA and SMAA (or any combination of AA) into one shader would speed up its performance or offer any benefits in any way since you're not loading multiple different shaders? Or maybe if its tweaked to remove redundant information that SMAA already covers and keep the other parts.

Also as a last question though both your SMAA and ASSMAA claim improved performance, what's the difference between the two?: https://github.com/lordbean-git/ASSMAA

[martymcmodding]

The result with 3x SMAA looks more painterly than accurate, similar to how DLSS tends to make the image appear. That's a result from repeated blurring and sharpening.

I mean it's subjective, but I think it looks worse. Single frame SMAA cannot solve temporal shimmering which is far worse than spatial aliasing. If a line is so thin it becomes dotted, SMAA can't reconnect them. Multiple AAs and sharpening effects tend to make this worse.

---

ASSMAA removed some code for faster edge detection, basically culling inactive code paths in multiplayer games. However, I don't actually think this brings measurable performance, but you can easily benchmark that ReShade gives timings in the statistics tab.

What I did was keeping all features but apply both microoptimization and on DX11+, leverage compute shaders for faster processing. Those weren't widely available when SMAA came out.

• Using compute, I can manually control how many threads are launched (as opposed to 1 per pixel)
• SMAA uses a stencil buffer to flag pixels for the expensive blend weight calculation. Clearing this buffer, flagging the pixels causes overhead and launching threads for all pixels (flagged or not) is very wasteful
• my compute variant launches fewer threads and processes multiple pixels at once, this causes fewer threads to twiddle their thumbs because their assigned pixels don't need processing. Further I can skip the stencil buffer usage.
• I optimized the area texture layout (dictionary for precomputed edge weights) for better cache hit rate

Honestly I hate to pull the "I did it better" card but lordbean really didn't do much about the effect. You don't have to trust me, compare on your end, use identical settings and see what the performance is. The most gains are gotten from highest settings due to static overhead, but it should be significantly faster across the board.

[xHybred]

I already benchmarked SMAA, ASSMAA and iMMERSE SMAA, so I already know yours is the fastest, but ASSMAA was also faster than regular SMAA. Combining these tweaks would result in further improvement?

Also unless I'm doing something wrong I did try the depth version of SMAA and it honestly didn't produce better results and in fact might've been worse than the standard/default detection method, is that suppose to happen? That part of SMAA felt kind of useless to me so nothing of value was lost in removing it if it means faster performance.

[martymcmodding]

I feel like gaining performance by removing features is a cheap solution, I wanted to keep SMAA vanilla in terms of features, just make it faster.

Also, SMAA edge detection has its use cases. Older games with low resolution textures and geometry basically only have aliasing on object borders and depth edge detection helps keeping the detected edge amount small, as more edge pixels = lower performance.

What would achieve the same thing however is just having the edge detection methods behind a preprocessor switch (as that literally removes code when disabled) but the performance mode in ReShade culls all unused code anyways so there remains no runtime cost caused by these features existing. Have you tried that?