Wednesday, June 22nd 2022
AMD Releases FidelityFX Super Resolution 2.0 Source Code Through GPUOpen
Today marks a year since gamers could try out AMD FidelityFX Super Resolution technology for themselves with our spatial upscaler - FSR 1. With the introduction of FSR 2, our temporal upscaling solution earlier this year, there are now over 110 games that support FSR. The rate of uptake has been very impressive - FSR is AMD's fastest adopted software gaming technology to date.
So it seems fitting that we should pick this anniversary day to share the source code for FSR 2, opening up the opportunity for every game developer to integrate FSR 2 if they wish, and add their title to the 24 games which have already announced support. As always, the source code is being made available via GPUOpen under the MIT license, and you can now find links to it on our dedicated FSR 2 page.Along with the FSR 2 API, and the full C++ and HLSL source code behind it, you'll also discover our Cauldron-based sample and comprehensive API documentation to help you with your integration. We put a lot of effort into the documentation to help developers with their integrations as much as possible, so you can add FSR 2 to your game or engine and really achieve the highest possible quality. Please check it out!
The version you'll be downloading today from GitHub is v2.0.1, which reflects the ongoing improvements we've been making since you would have first seen FSR 2 in action earlier this year.
FSR 2 supports both DirectX 12 and Vulkan, with plugins for Unreal Engine 4.26/4.27 and Unreal Engine 5 due very soon. It will also be available through the Xbox Game Development Kit.
We've also updated the FSR 2 page here on GPUOpen - you'll find new screenshot comparisons and updated content.
Note that FSR 1 can still be exposed as its own upscaling option in addition to FSR 2 in game titles. Both technologies have different characteristics which may be suitable for a wider range of platforms and user preferences. For example, our FSR 2 partner title DEATHLOOP exposes both.
We're really excited to finally get the source code, docs, and the sample out to developers, so head over to our updated FSR 2 page now to see what's new!
So it seems fitting that we should pick this anniversary day to share the source code for FSR 2, opening up the opportunity for every game developer to integrate FSR 2 if they wish, and add their title to the 24 games which have already announced support. As always, the source code is being made available via GPUOpen under the MIT license, and you can now find links to it on our dedicated FSR 2 page.Along with the FSR 2 API, and the full C++ and HLSL source code behind it, you'll also discover our Cauldron-based sample and comprehensive API documentation to help you with your integration. We put a lot of effort into the documentation to help developers with their integrations as much as possible, so you can add FSR 2 to your game or engine and really achieve the highest possible quality. Please check it out!
The version you'll be downloading today from GitHub is v2.0.1, which reflects the ongoing improvements we've been making since you would have first seen FSR 2 in action earlier this year.
FSR 2 supports both DirectX 12 and Vulkan, with plugins for Unreal Engine 4.26/4.27 and Unreal Engine 5 due very soon. It will also be available through the Xbox Game Development Kit.
We've also updated the FSR 2 page here on GPUOpen - you'll find new screenshot comparisons and updated content.
Note that FSR 1 can still be exposed as its own upscaling option in addition to FSR 2 in game titles. Both technologies have different characteristics which may be suitable for a wider range of platforms and user preferences. For example, our FSR 2 partner title DEATHLOOP exposes both.
We're really excited to finally get the source code, docs, and the sample out to developers, so head over to our updated FSR 2 page now to see what's new!
28 Comments on AMD Releases FidelityFX Super Resolution 2.0 Source Code Through GPUOpen
Ultra Quality
Quality
Balanced
Performance
But now it's going to be
Quality
Balance
Performance
Ultra Performance
I want to say Ultra Quality was like rendering at like 3200x1800 if your native screen res is 4K
So now, for example, the best setting you could use is quality which renders at 2560x1440
I like everything I've read so far except this change! If you need to use "ultra performance" then you should just be lowering your display's resolution. It's only 33%!!! Because yea a lot of ppl on 4K screens want to play a game at 720p! Imagine how shitty that will look for ppl on 1080p or even 1440p displays! Might as call it "make your game look like it was designed for the Gamecube or N64" at that point
On to the subject at hand, this is great. I expect FSR 2.0 to gain more ground, and become, at the very least, a constant companion to games that are implementing DLSS due to it being supported on all graphics cards.
So NVidia users should keep using DLSS no matter what right now. It's also in some situation doing a better job for case that FSR 2.0 doesn't handle very well yet.
A possible reason for the lack of ultra quality is FSR 2.0 rely on the compute units of the GPU. It have a cost and it's not sure if a Ultra quality would provide enough performance to offset the cost of the upscaling. We will see as that might come in the future.
They still have some work to do, but it's very interesting and it's good to have a good vendor agnostic solution that everyone can use.
Personally, my guess is DLSS would still be a selling point, and consumer would probably give NVIDIA a bit of extra point when considering which VGA to buy, whilst FSR 2.0 become wipespread, but doesn't really benefit AMD as it is normalized as new baseline like freesync.
However
Are you old enough to remember VHS and Betamax?
If you can reach the vast majority of the installed base with one tech while you only reach a small minority with another similar competing tech, the more widely usable one can sway the market towards adopting that pan-usable tech.
DLSS didn't gain a lot of traction probably because it's expensive to implement and now that a similar and simpler technology exists that work in a much wider market (that even includes consoles) it pretty much only has a destination, the graveyard of interesting but proprietary and closed tech.
Freesync vs gsync has nothing to do with hdmi vs display port, it just so happens that the gsync module is now outdated and since vesa freesync technology became much more widespread (by being open... what a shocker) nvidia doesn't seem to care to update the module because there aren't that many advantages on gsync over freesync anyway and they weren't able to make it standup in the market when the tech was new let alone when it's now common place to have freesync on everything (with hdmi even adopting it for their vrr tech)
Regarding Display Port vs HDMI, Display Port is actually somewhat more open, I don't know why HDMI was able to become the standard for consumer AV equipment, maybe they were more open to going along with copyright cartels about HDCP stuff and are more willing to play along with manufacturers shenanigans making the features of the standard all optional (great for the consumers of course.. :nutkick:), HDMI 2.1 may now be better than DP 1.4 but they're basically always one upping each other with each revision.
For those who were saying DLSS is an open source feature. DLSS was never an open source feature FSR 2.0 is in all extent and that is what DLSS should have been.
Going to be an awesome few years + of reconstruction / Upscaling advancement for everyone.
DLSS, TSR, FSR, XeSS... Fascinating stuff.
And don't get me started on the whole "we use a supercomputer" to enhance DLSS. I call BS on that, or it is how nGreedia slaves devs into paying for it. AMD have got so close to DLSS without resorting to underhanded tactics and magical A.I.