AMD FidelityFX Super Resolution

[Je06jm]

AMD FidelityFX Super Resolution, which will be referred to as FSR, can be applied to any viewport through code or in the editor. FSR is applied after all post processing effects. In it's current form, it's only implemented in a compute shader so it will not work with the mobile renderer.

FSR has a few advanced settings in the project settings menu under rendering/scaling 3d. In addition, these properties can be accessed in the SubViewport node under upscaling. Finally, a few new viewport properties have been exposed, namely scaling_3d_mode, scaling_3d_quality, fsr_mipmap_bias, and fsr_sharpness

Bugsquad edit: This closes godotengine/godot-proposals#2809.

[Calinou]

Things that needs to be done before ready for a pull request are:

• Adjust mipmap bias

See #38569, but it needs to be done in a different way to allow run-time adjustments. We could then have the FSR setting apply an automatic additional bias to the LOD bias project setting.

[fire]

I noticed you're a first time contributor.

If you need with the cicd errors, shout. Also see https://docs.godotengine.org/en/stable/community/contributing/pr_workflow.html

[Je06jm]

@fire Thanks for the offer, but I got it. They are mostly silly errors on my part involving not running clang-format and not running --doctool

[Je06jm]

At the moment, I'm having trouble figuring out how to apply FSR to the main 3d viewport. If anyone has any ideas, I would appreciate it. I can enable it through gdscript at runtime, I want to be able to apply the default settings from the project settings

[clayjohn]

@Je06jm maybe in main.cpp?

godot/main/main.cpp

Line 1844 in 8781c95

bool Main::start() {

edit: actually probably during initialization of the scene_tree

godot/scene/main/scene_tree.cpp

Line 1317 in 8781c95

SceneTree::SceneTree() {

[Je06jm]

@clayjohn That does work for 3d scenes, but not for 2d scenes. I'm not sure how to tell if a scene is 3d or 2d from the initialization of the scene_tree

[Calinou]

@clayjohn That does work for 3d scenes, but not for 2d scenes. I'm not sure how to tell if a scene is 3d or 2d from the initialization of the scene_tree

Shaders in the tonemap pass like FXAA and debanding are only effective on 3D scenes. 2D elements are not affected by those shaders, even if they are enabled. This is a good thing in FSR's context, because FSR should not be applied on 2D elements like the GUI. As for 2D games, it's less common for them to run into performance issues because they are run at high resolutions compared to 3D games.

[Je06jm]

@Calinou Sorry for the confusion. I need to detect when the root is a 2d scene so that I can disable FSR

[mrjustaguy]

AMD's FSR has issues with Godot's SDFGI

UP - DOWN arrows for switching between FSR Disabled and FSR Performance
SDFGI.zip

Native

FSR

Aside from This Issue I Haven't Found any other Problems, and I must say, AMD really impressed me, in my testing, I've seen a performance uplift anywhere from 50% to 200% (from 10 to 30 FPS in my Stress tests, from 40 to 60 in less demanding tests) depending on The Scene when using Performance Mode and upscaling from 540p to 1080p on an antique low end potato of a GPU (Quadro K2000 - a Slightly weaker 650 with 2GB memory), which is well worth the slight image quality degradation

[Chaosus]

I've rebased this to fix a conflict + fixed a newline at the end of some files

[fire]

@@@ -2524,6 -2575,11 +2576,14 @@@ EffectsRD::~EffectsRD() 
        RD::get_singleton()->free(index_buffer); //array gets freed as dependency
        RD::get_singleton()->free(filter.coefficient_buffer);
  
++<<<<<<< HEAD
++=======
+       RD::get_singleton()->free(ssao.mirror_sampler);
+       RD::get_singleton()->free(ssao.gather_constants_buffer);
+       RD::get_singleton()->free(ssao.importance_map_load_counter);
+ 
+       FSR_upscale.shader.version_free(FSR_upscale.shader_version);
++>>>>>>> remotes/Je06jm/fsr
        if (prefer_raster_effects) {
                blur_raster.shader.version_free(blur_raster.shader_version);
                bokeh.raster_shader.version_free(blur_raster.shader_version);
~

[fire]

Unused code should be deleted rather than commented out.

Also use // instead of /* */

[Je06jm]

Everything is now working except for changing the mipmap lod bias

[Ansraer]

Honestly, I am not familiar enough with godots renderer to properly evaluate this, but from what I can tell this looks very promising. Some small nitpicks I noticed while reading this on my phone, nothing too major.

[Ansraer]

I am no expert, but this looks good to me. Thanks for spending the time to implement this!

[Je06jm]

That's interesting. Does the checks not test MoltenVK? What would happen if you changed servers/rendering/renderer_rd/effects_rd.cpp line 1934 from \n#define MODE_FSR_UPSCALE_NORMAL\n" to \n#define MODE_FSR_UPSCALE_FALLBACK\n?

It is compiling with MODE_FSR_UPSCALE_FALLBACK.

Alright. I'll work on forcing the fallback mode when using MoltenVK. I'll also create an issue reporting this problem

[Je06jm]

Also @bruvzg, did this error happen when compiling source or when running Godot?

[bruvzg]

Also @bruvzg, did this error happen when compiling source or when running Godot?

When running.

[Je06jm]

@bruvzg I just updated the PR so it should now work on MoltenVK

[clayjohn]

Re-approving given the changes since my last review

[Calinou]

I made a testing project: test_fsr.zip

Tests below were run on a GeForce GTX 1080 with NVIDIA 470.74 driver.

Bilinear scaling works as expected, although the aforementioned FSR mipmap bias setting doesn't seem to have an effect (see my above review comment). Ideally, the mipmap bias setting should always work, even if the scale factor is 1.0 (it can be used to make textures appear sharper at a distance).

This is likely controlled here: https://github.com/Je06jm/godot/blob/20deb0917d466ca9dd1bf435dfb326c72f73e3c0/servers/rendering/renderer_rd/renderer_scene_render_rd.cpp#L2673-L2677

FSR appears to be broken in this project until Glow is disabled. I only get a black screen with 2D elements not being cleared after every frame is rendered:

After restarting the editor, I get this error spam:

ERROR: Uniforms were never supplied for set (0) at the time of drawing, which are required by the pipeline
   at: compute_list_dispatch (drivers/vulkan/rendering_device_vulkan.cpp:8086)
ERROR: Texture (binding: 0, index 0) is not a valid texture.
   at: uniform_set_create (drivers/vulkan/rendering_device_vulkan.cpp:5603)
ERROR: Condition "!uniform_set" is true.
   at: draw_list_bind_uniform_set (drivers/vulkan/rendering_device_vulkan.cpp:7271)
ERROR: Uniforms were never supplied for set (2) at the time of drawing, which are required by the pipeline
   at: draw_list_draw (drivers/vulkan/rendering_device_vulkan.cpp:7426)

Edit: It looks like disabling Glow in WorldEnvironment fixes this. Rendering stops working again as soon as I enable glow again.

Either way, kudos for sticking around and implementing FSR all the way 🙂

[Je06jm]

@Calinou. That is an interesting bug. I'll start working on that. As far as mipmap mipmap bias, I agree that it would be useful outside of FSR. That will be in the next PR as well.

[Je06jm]

@Calinou After some investigating, I discovered that the problem is that when the render texture's resolution is too low, the blur texture does not get allocated. The error I'm getting there is that Too many mipmaps requested for texture format and dimensions (10), maximum allowed: (9). It looks like the code that calculates how many mipmaps to request has a bug in it that only affects really low resolutions. Should this be fixed here or in a separate PR?

[Calinou]

Should this be fixed here or in a separate PR?

I guess it should be fixed in a separate PR 🙂

[akien-mga]

Thanks for the great feature, and all the edits to match our requirements! And congrats for your first merged Godot contribution 🎉

[Je06jm]

@akien-mga Thanks! Unfortunately, there was one last thing I was going to change. As me and @Calinou discussed, I was going to make mipmaps bias apply even if FSR is disabled. Should I open a new PR for this?

[akien-mga]

Yes, a new PR would be fine :)

[Calinou]

Note that if anyone is interested on bringing FSR to mobile/low-end platforms, it would be best to add a "FSR Lite" scaling option as demonstrated here: https://atyuwen.github.io/posts/optimizing-fsr/
See the commits that added FSR Lite to the original FSR sample: https://github.com/atyuwen/FidelityFX-FSR/commits/master

FSR Lite looks a bit worse than vanilla FSR, but it performs much better on mobile GPUs and integrated graphics. It's fast enough to be usable on mid-range/high-end mobile.

[unfa]

I am still having issues with FSR. It doesn't work at all when Glow is enabled (produces a weird glitches with transparent 2D on top of the 3D layer).

Even then it doesn't seem to work, and some particle effects are glitched out, rendering in a 2x smaller plane mismatched to the rest of the viewport. That's at 50% scale. At 25% scale the display breaks entirely as if the texture mapping to the viewport quad is completely broken.

[clayjohn]

@unfa please make a bug report. Comments made on PRs will get lost.