AMD FSR antialiasing discussion

  • Thread starter Deleted member 90741
  • Start date
I despise oversharpening. In fact I'm often repulsed by what many people may consider "mild/moderate" sharpening. That DLSS shot does not look oversharpened to me. I don't see any telltale halos. It just seems to be resolving more detail.
Static scenes are fine mostly with DLSS. But the halos are really bad on camera motions for whatever reason, and the only way to remove them is to set DLSS sharpness in game to 0 (and then use some external sharpener if the result will look too soft).
 
Interesting comments from Guerilla on checkerboarding vs other reconstruction techniques like FSR 2.0

In the age of 'next generation' upscaling techniques, there's been some confusion as to why Guerrilla persisted with checkerboard rendering and the studio was happy to give a few reasons why.

"DLSS 2.0, FSR 2.0 and checkerboard rendering are all different ways to render fewer pixels per frame than the actual output has, and then reconstruct a higher-res result over time," explains Giliam de Carpentier. "And so, this means that the distance between rendered pixels is always going to be bigger than the distance between output pixels. But with checkerboard rendering, the distance between rows and columns in the rendered image and resolved image will still remain the same, which means that most edges (being typically either mostly horizontal or mostly vertical) won't be able to 'fall through the cracks' as easily and therefore won't as easily get missed completely one frame and be visible the next again.

"This results in data that has the potential to keep thin edges more stable more reliably but is also more complex to use optimally. But the new custom AA resolve is a definite step up in tapping into this potential, by distinguishing much more reliably between data than can be reused (in order to reduce shimmering), and data that has gotten too different (in order to prevent ghosting). And this is still paired with our checkerboard-compatible version of FXAA as well to make the most out of even single-frame data."

I'd say from the results in FW, and especially compared to the above video on GoW with FSR 2.0, they've made the right call (albeit not like they could probably implement and test FSR 2.0 in the timeframe regardless). As others have said this is part of the reason why FSR 2.0 is not necessarily some 'game changer' for consoles as there have been existing reconstruction methods used for years with decent to excellent results - it's different on the PC where there's a relative paucity of these techniques.
 
Last edited:
But with checkerboard rendering, the distance between rows and columns in the rendered image and resolved image will still remain the same, which means that most edges (being typically either mostly horizontal or mostly vertical) won't be able to 'fall through the cracks' as easily and therefore won't as easily get missed completely one frame and be visible the next again.
This stuff is highly arguable. There are other ways around how edges can be kept at better than native quality and without constraints of checkerboarding.
The main flaw of checkerboarding is the fixed 2x upscaling ratio, while TAAU and its derivatives can easily fluctuate between 33% to 100% res rendering.
I would not be surprised if TAAU has better chances of providing close to native experience vs a combination of checkerboarding and following spatial upscaling to native when perf targets are not met.
TAAU variations are also more versatile, easier to implement and maintain, doesn't have checkerboarding related performance overheads, I guess that's the reasons why checkerboarding is dead on PC, not the other way around.
As far as I remember the checkerboarding was dropped off even from the Rainbow Six Siege (to cut down maintaining costs most likely), the game where it was implemented for the first time on PC and consoles.
So I don't think checkerboarding is a viable alternative for anyone, but a few Sony studios.
 
Last edited:

Oh that's cool, first game that doesn't already have DLSS that got FSR 2.0 I think?
 
Early observations indicate ghosting might be an issue in TinyTW with FSR 2.0 enabled, similar to GOW. Incoming reviews should be interesting for this game.
 

These additional (vs. DLSS) two inputs are the main quality factors that game devs should aware.
And it seems not easy as the results showing..

Reactive mask
In the context of FSR2, the term "reactivity" means how much influence the samples rendered for the current frame have over the production of the final upscaled image. Typically, samples rendered for the current frame contribute a relatively modest amount to the result computed by FSR2; however, there are exceptions. To produce the best results for fast moving, alpha-blended objects, FSR2 requires the Reproject & accumulate stage to become more reactive for such pixels. As there is no good way to determine from either color, depth or motion vectors which pixels have been rendered using alpha blending, FSR2 performs best when applications explicity mark such areas.

Therefore, it is strongly encouraged that applications provide a reactive mask to FSR2. The reactive mask guides FSR2 on where it should reduce its reliance on historical information when compositing the current pixel, and instead allow the current frame's samples to contribute more to the final result. The reactive mask allows the application to provide a value from [0..1] where 0 indicates that the pixel is not at all reactive (and should use the default FSR2 composition strategy), and a value of 1 indicates the pixel should be fully reactive.

While there are other applications for the reactive mask, the primary application for the reactive mask is producing better results of upscaling images which include alpha-blended objects. A good proxy for reactiveness is actually the alpha value used when compositing an alpha-blended object into the scene, therefore, applications should write alpha to the reactive mask. It should be noted that it is unlikely that a reactive value of close to 1 will ever produce good results. Therefore, we recommend clamping the maximum reactive value to around 0.9.

If a Reactive mask is not provided to FSR2 (by setting the reactive field of FfxFsr2DispatchDescription to NULL) then an internally generated 1x1 texture with a cleared reactive value will be used.

Transparency & composition mask
In addition to the Reactive mask, FSR2 provides for the application to denote areas of other specialist rendering which should be accounted for during the upscaling process. Examples of such special rendering include areas of raytraced reflections or animated textures.

While the Reactive mask adjusts the accumulation balance, the Transparency & composition mask adjusts the pixel locks created by FSR2. A pixel with a value of 0 in the Transparency & composition mask does not perform any additional modification to the lock for that pixel. Conversely, a value of 1 denotes that the lock for that pixel should be completely removed.

If a Transparency & composition mask is not provided to FSR2 (by setting the transparencyAndComposition field of FfxFsr2DispatchDescription to NULL) then an internally generated 1x1 texture with a cleared transparency and composition value will be used.
 
FOSS is a great thing :)

AMD did say they made it simple if game already had DLSS, but this shows the interfaces and data structures to be even closer than expected.

I expect Nvidia to try their hardest to break this in their next update.
The last thing they want is people being able to do this based on their previous responses, even if it doesn't look as good due to not being fully implemented.
 
FOSS is a great thing :)


Technically, it doesn't need to be fully open source to be integrated into other software. If the proper API/ABI is provided, that's enough.
 
AMD did say they made it simple if game already had DLSS, but this shows the interfaces and data structures to be even closer than expected.

I expect Nvidia to try their hardest to break this in their next update.
The last thing they want is people being able to do this based on their previous responses, even if it doesn't look as good due to not being fully implemented.

There is nothing to break. It was nVidia who made DLSS "open" aka definition of the input informations towards the dll.
 
AMD did say they made it simple if game already had DLSS, but this shows the interfaces and data structures to be even closer than expected.

I expect Nvidia to try their hardest to break this in their next update.
The last thing they want is people being able to do this based on their previous responses, even if it doesn't look as good due to not being fully implemented.

What responses? UE5 exposes a common interface for upscaling shared by TAAU and DLSS. It is likely similar for other engines. There’s nothing for Nvidia to “break”.
 
A funnier turn out would be if some game would implement FSR2 via a similar interface and one would be able to "upgrade" that to DLSS by switching the DLL. But alas I doubt that FSR2 games will use the DLL approach.
 
AMD did say they made it simple if game already had DLSS, but this shows the interfaces and data structures to be even closer than expected.

I expect Nvidia to try their hardest to break this in their next update.
The last thing they want is people being able to do this based on their previous responses, even if it doesn't look as good due to not being fully implemented.
Nvidia is doing the opposite, creating a unified API for developers to have access to multiple upscaling methods with minimal effort. See Streamline

Nvidia has little to gain from making DLSS difficult to integrate. If a developer deems FSR2 (or XeSS) 'close enough' and doesn't bother with DLSS, nvidia loses a competitive advantage. On the flipside if it's easy for a developer to ship both, nvidia can still claim better image quality and performance with DLSS that's exclusive to their cards.
 
Last edited:
The Interface description being open and known is very different.
Example: youtube may have api that everyone knows, doesn't mean they don't purposely break things that use it.

Nvidia has marketing with a lot of games, so I don't see them being open to people easily modding in FSR2 if they can stop it.
Having similar interface is one thing, paying for marketing is another.

I personally won't be surprised if future DLSS versions won't allow easy modding.
But we'll see, something we'll have to revisit.
 
Back
Top