AMD FidelityFX Super Resolution Source Code Coming Next Month

[zakhrov]

I'm just saying here, since there is no code yet BUT BUT it may be possible to use it with VkBasalt + CAS and that basically fix all games BUT well we have to wait until the code drop

From what I can tell FSR needs to be implemented before the final post processing stage. That means games need to specifically integrate it into their rendering pipelines. I hope Feral Interactive can patch it into their Tomb Raider and Deus Ex game ports

[skeevy420]

Hopefully this is something that can be added in at a graphics API or game engine level because, to be straight up honest, I don't have any of those existing or upcoming games nor do either of those groups contain games that I'd like to buy.

[skeevy420]

to add another here is gamers nexus: https://www.youtube.com/watch?v=KCzjQ4qP124

steve did say, technically, FSR can actually work further back than polaris 470 for amd and further back than the 1060 from nvidia. its just not officially supported. but steve said its "not bad." which is pretty big since he usually nitpicks everything.

I guessed correctly on his blind FSR test

I'd have been interested to see simple integer upscaling in the comparisons as well. I integer upscale most games from 1080p to 4K because my 580 can't handle 4K low with most games while 1080p60 Custom Ultra (med/low shadows ) is just fine.

[jrch2k8]

From what I can tell FSR needs to be implemented before the final post processing stage. That means games need to specifically integrate it into their rendering pipelines. I hope Feral Interactive can patch it into their Tomb Raider and Deus Ex game ports

Well, it says is better before post processing which makes sense since it may loose performance up scaling those as well but i'm not sure due to how Vulkan layers work if VkBasalt could do this on its own since it could detect this stage(again not sure), in the case of proper DX12 i think it doesn't allow anything similar to layers in Vulkan hence you will need engine patching.

In the worst case scenario i wouldn't mind an extra performance hit if VkBasalt had to include PP as long as it gets a nice enough boost

[oiaohm]

I guessed correctly on his blind FSR test

I'd have been interested to see simple integer upscaling in the comparisons as well. I integer upscale most games from 1080p to 4K because my 580 can't handle 4K low with most games while 1080p60 Custom Ultra (med/low shadows ) is just fine.

The review I posted link to by hardware Unboxed put amd Fidelity FX Super Scaling head to with the common simple upscale what they call traditional upscale and it won with out question. This is something different to your traditional integer upscale it is better in most cases. This is why I am interested from photo point of view exactly how is amd doing it.

[oiaohm]

Well, it says is better before post processing which makes sense since it may loose performance up scaling those as well but i'm not sure due to how Vulkan layers work if VkBasalt could do this on its own since it could detect this stage(again not sure), in the case of proper DX12 i think it doesn't allow anything similar to layers in Vulkan hence you will need engine patching.

In the worst case scenario i wouldn't mind an extra performance hit if VkBasalt had to include PP as long as it gets a nice enough boost

Interesting point here is with wine own implementation of dx12 the fact Microsoft did not include the layers feature does not mean wine cannot use it. This could get interesting.

[arQon]

Well, it says is better before post processing which makes sense since it may loose performance up scaling those as well

Performance is (basically) irrelevant. The difference is that when you do stuff like this as an independent postproc step, you only have image data to work with - i.e. the flat representation of the output frame. If you do it earlier in the pipeline though, you have *geometry / depth* data available as well, and that makes it trivial to avoid some of the "obvious error" cases where simple upsampling blends together two pixels that are 500 yards away from each other in z.

[oiaohm]

Performance is (basically) irrelevant. The difference is that when you do stuff like this as an independent postproc step, you only have image data to work with - i.e. the flat representation of the output frame. If you do it earlier in the pipeline though, you have *geometry / depth* data available as well, and that makes it trivial to avoid some of the "obvious error" cases where simple upsampling blends together two pixels that are 500 yards away from each other in z.

This is why I will be interested to see how they are doing it. A real world photo with real world lighting before processing you can in fact pull a 3d model back out of it. So depending on what inputs FidelityFX Super Resolution needs it might be possible to generate them if so this could be a new method for upscale sections of photos. Lot of people don't think there is Z data in photos.

Be it photos or game images the postproc steps in fact take away a lot of data that result in a lot of artefacts when you attempt to upscale. Even simple upsampling you are in trouble. Yes Z info can help but you think about added static/rain effects yes you know it on a different Z yes you know it should not be blended with z infomation but if you are after it was added you don't know what colour the pixels were behind it the same thing applies to hud and same thing applies to edge of screen. Basically the missing details comes a big problem even for simple upsampling.

[skeevy420]

The review I posted link to by hardware Unboxed put amd Fidelity FX Super Scaling head to with the common simple upscale what they call traditional upscale and it won with out question. This is something different to your traditional integer upscale it is better in most cases. This is why I am interested from photo point of view exactly how is amd doing it.

After watching it I hear you there. Especially on the photo POV. Would be cool to have an extreme quality mode to use for GIMP upscaling and other situations where render time isn't key.

[jrch2k8]

Performance is (basically) irrelevant. The difference is that when you do stuff like this as an independent postproc step, you only have image data to work with - i.e. the flat representation of the output frame. If you do it earlier in the pipeline though, you have *geometry / depth* data available as well, and that makes it trivial to avoid some of the "obvious error" cases where simple upsampling blends together two pixels that are 500 yards away from each other in z.

Yeah i get your point but what i am getting at is that VkBasalt is already able to use pretty invasive Reshade shaders and sharpening filters including CAS and at least for me they don't destroy the image hence i suspect there must be some layers magic behind it to get all that information(or some).

In my case i use a very heavily modded skyrim SE with latest ENB (RADV+Wine-TKG), ultra high res textures and instead of using Reshade(aka the classic ENB+Reshade setup) windows binaries i use their config file and translate it (manually) to VkBasalt Reshade and works like a freaking charm plus CAS to improve sharpness without any issue.

We have to wait until the source code drop but again i suspect VkBasalt may have a way through layers to actually get information of the render stages and pass them to the shaders in certain order because with a setup as complex as my skyrim all those shaders never break actual PP or trigger render issues.

Ofc i might be wrong here since Vulkan is not my forte