Today AMD released FidelityFX Super Resolution, their attempt to answer NVIDIA's DLSS and the source code to it is coming soon for developers to look at. Update 24/06/21 - it does actually work on Linux both in native titles (like Dota 2) and Steam Play Proton - even for NVIDIA GPUs.
What exactly is it then? It's AMD's solution for producing high resolution frames from lower resolution inputs. From what AMD say: "it uses a collection of cutting-edge algorithms with a particular emphasis on creating high-quality edges, giving large performance improvements compared to rendering at native resolution directly. FSR enables “practical performance” for costly render operations, such as hardware ray tracing.".
It supports Vulkan and DirectX, although currently it seems it's actually limited to Windows as mentions of Linux have been absent from any press materials and official announcements from AMD. Once it's properly open source, which AMD say will happen "mid July" on GPUOpen, there should hopefully be nothing to stop Mesa developers hooking up support for it to then work for Linux native titles and Windows games run through Steam Play Proton. The latest "official" AMD driver (being the Radeon Software for Linux) had an update only yesterday, June 21, which simply bumped up the supported Linux distribution version.
Direct Link
AMD's version will at least work across both NVIDIA and AMD GPUs, which may make it end up becoming more of a standard compared to DLSS but they face an uphill battle since NVIDIA has a firm foothold with DLSS already.
Quoting: KROMNow, if they finally would create a new control center for Linux to configure all that fancy stuff, that'd be awesome.
And ideally make it open as well. :-)
QuoteAMD's version will at least work across both NVIDIA and AMD GPUs, which may make it end up becoming more of a standard compared to DLSS but they face an uphill battle since NVIDIA has a firm foothold with DLSS already.
I think for many of us Nvidia gamers, the big thing AMD brings to the table is the fact that it works on non-RTX 10xx cards too. Unlike DLSS.
Quoting: KROMNow, if they finally would create a new control center for Linux to configure all that fancy stuff, that'd be awesome.
Why? What would be in such a control centre? One of the things I love about AMD's design on Linux is explicitly NOT having any configuration to do. I just tick, or untick vsync in each game and it works (whereas on Nvidia, it was a coin-toss if it did anything at all).
Quoting: KROMNow, if they finally would create a new control center for Linux to configure all that fancy stuff, that'd be awesome.Personally I would prefer if they release the necessary config parameters of the said "control center" instead of launch one of their on, so different distros/DEs could easily integrate those configs in their specifics control panels and avoiding the risk of conflicts between both of them.
But yeah, it's bad if the only option is to manually change those through text commands.
So they are gonna drop the source online and hope the community picks up the slack. Might work.
Quoting: GuestAs far as I know, FSR is basically a couple of shaders? So I wonder if it could be injected to any game via something like vkBasalt. Pretty sure it wouldn't be quite something so simple. Suppose I should read up on it more to know if that would be viable. It'd definitely be very cool if it was, just from a technical perspective, even if I wouldn't really benefit much personally from this kind of thing.If it has some particularly tasty rescaling algorithms, a nicer place to pick it up would be gamescope if, say, there were some performance-constrained AMD hardware that was habitually upscaling.
Pretty impressed.
Quoting: GuestAs far as I know, FSR is basically a couple of shaders? So I wonder if it could be injected to any game via something like vkBasalt. Pretty sure it wouldn't be quite something so simple. Suppose I should read up on it more to know if that would be viable. It'd definitely be very cool if it was, just from a technical perspective, even if I wouldn't really benefit much personally from this kind of thing.Well, of course you can upscale and sharpen the image as post-processing effect but then you are upscaling everything, HUD text and all included. By being implemented into the game you can affect only particular parts, and let HUD and text still render in full scale without losing image quality.
Last edited by Solitary on 22 June 2021 at 9:57 pm UTC
Take Note. This is what <3 Linux looks like.
Big props to AMD, proud to be a AMD consumer on all my home & office electronics the last 5 years.
Open Source AMD stuff on Linux is so nice.
I did see a comment that it needs to be applied too early in the pipeline for it to be added as a post-processing shader. The game itself has to add support for it.
Ironically DLSS is supported in MUCH MORE games atm thanks to mainstream engines adopting them such as UnrealEngine having it baked in. However gamedevs still need to send off textures to NVIDIA for processing, but maybe one day developers will have access to those tools themselves and NVIDIA won't need to be involved (we can only hope).
Still unsure if my next card will be a RDNA3 or NV4000...
Last edited by TheRiddick on 23 June 2021 at 2:33 am UTC
Quoting: TheRiddickHowever gamedevs still need to send off textures to NVIDIA for processing, but maybe one day developers will have access to those tools themselves and NVIDIA won't need to be involved (we can only hope).They don't.
The AI for DLSS 1 needed to be trained on "what this game should look like" to provide its results, and the per-game magic numbers were included along with the per-game optimisations in the fat Windows driver.
The AI for DLSS 2 is trained on "what games look like" and the one set of magic numbers is used for everything.
Devs need to include motion vectors and the previous upscaled frame in their engine to use the DLSS mechanism for the next frame.
Edit: Also works in Dota 2 if you're using Vulkan.
Last edited by Liam Dawe on 24 June 2021 at 8:22 am UTC
See more from me