# Using AMD FSR with babylon.js **URL:** \ **Category:** Questions\ **Tags:** gpu, memory\ **Created:** [March 24, 2023, 1:55pm UTC](https://forum.babylonjs.com/t/using-amd-fsr-with-babylon-js/39326 "2023-03-24T13:55:43Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![kzhsw](https://avatars.discourse-cdn.com/v4/letter/k/848f3c/32.png) [@kzhsw](https://forum.babylonjs.com/u/kzhsw)\ **Post date:** [March 24, 2023, 1:55pm UTC](https://forum.babylonjs.com/t/using-amd-fsr-with-babylon-js/39326/1 "2023-03-24T13:55:43Z")
Update Aug.2026: It’s landed! > > > \[Created by Copilot on behalf of @bghgary\] > > \## Context > > This continues #1699…4 by @matanui159 (Jasmine Minter), which implemented AMD \*\*FSR 1\*\* (EASU upscale + RCAS sharpen) as fragment post-processes (a \`PostProcessRenderPipeline\`) in WGSL. That PR was \*\*WebGPU-only\*\* because the EASU pass uses \`textureGather\`, which Babylon's GLSL target doesn't expose — so it did not run on WebGL2 or Babylon Native. > > Full credit for the original FSR 1 pipeline and shaders goes to Jasmine; her commit is preserved as the first commit here and this PR builds directly on it. > > \## Change > > \- Adds \*\*GLSL (\`Shaders/\`) variants\*\* of the EASU / RCAS shaders and the \`ffxFunctions\` include, so the pipeline runs on \*\*WebGL2 and Babylon Native\*\* in addition to WebGPU. The EASU \`textureGather\` calls are rewritten as 4 explicit \`texelFetch\`es (in gather order) — the approach the original author suggested; RCAS uses plain texel loads and ports unchanged. > \- The thin post-processes select WGSL vs GLSL via \`\_gatherImports\`, the same pattern as FXAA / TAA. > \- Switches the effects to \*\*plain uniforms\*\* (\`con0..con3\` / \`con\`) set from \`onApplyObservable\` instead of a uniform buffer, so they work on backends that disable uniform buffers (Babylon Native). Shaders are simplified accordingly (dropped the \`uint\`→\`float\` bit-casts and the UBO/struct declarations). > \- \`isSupported\` is \`isWebGPU || engine.version \>= 2\` (WebGPU / WebGL2 / Native → true; WebGL1 → false). > \- Fixes an FSR shader crash on the D3D11 / Babylon Native swapchain. > > \## Behavior > > Purely additive: a new opt-in \`FSR1RenderingPipeline\`. No existing behavior changes — WebGPU output is unchanged, and the WebGL2 + Native paths are newly enabled. > > \## Validation > > \- Shaders compile to SPIR-V via glslang (Native's toolchain) and validate as GLSL ES 3.00 (WebGL2). > \- Rendered a scene through the FSR 1 pipeline on Babylon Native's D3D11 backend — correct upscaled output, clean exit. > \- Visualization test \`FSR1 render pipeline\` runs a photographic source through the pipeline. It moves 12.21% of pixels against a naive upscale of the same half-resolution source, versus the harness's 1.1% gate. > > \## Try it > > \[FSR1 A/B toggle playground\](https://playground.babylonjs.com/?snapshot=refs/pull/18723/merge#GB98SV#0) — cycles FSR1, a naive bilinear upscale of the same half-resolution source, and a native full-resolution render. Tap, space, or 1-3 to switch; drag to orbit and wheel to zoom in on the reconstruction. > > Judge FSR against the naive upscale rather than the native render: the pipeline renders at half resolution, so switching it off is always sharper and that is not a defect. > > Credit: @matanui159 (Jasmine Minter) for the original FSR 1 pipeline, #16994. > **[Release 9.21.1 · BabylonJS/Babylon.js](https://github.com/BabylonJS/Babylon.js/releases/tag/9.21.1)** > > Core > > Fix WebGPU rendering nothing when maxSimultaneousLights exceeds the uniform buffer budget - \[Bug Fix\] by bkaradzic-microsoft (#18797) > FSR 1 render pipeline (EASU + RCAS) with WebGL2 / Native ... Background: 1. On making a page to work with some high-resolution screens, we found that the gpu memory is too easy to run out, the [setHardwareScalingLevel](https://doc.babylonjs.com/typedoc/classes/BABYLON.Engine#setHardwareScalingLevel) can reduce the use of gpu memory by making the scene really blur. 2. AMD FidelityFX Super Resolution (FSR) is a spatial upscaling technology that allows games to be rendered at a lower resolution and then upscaled to a higher resolution without a significant loss in image quality. Existing work: 1. The [homepage](https://gpuopen.com/fidelityfx-superresolution/) of FSR 2. The [FidelityFX-FSR](https://github.com/GPUOpen-Effects/FidelityFX-FSR) github repo 3. A [blog article](https://jntesteves.github.io/shadesofnoice/graphics/shaders/upscaling/2021/09/11/amd-fsr-demystified.html) about fsr 4. shader codes on shadertoy: - [https://www.shadertoy.com/view/sl3cz8](https://www.shadertoy.com/view/sl3cz8) - [https://www.shadertoy.com/view/stXSWB](https://www.shadertoy.com/view/stXSWB) 5. [https://github.com/Hajime-san/web-fsr](https://github.com/Hajime-san/web-fsr) based on three.js 6. [https://github.com/BenjaminWegener/AMD-fidelityFX-SuperResolution-webGL](https://github.com/BenjaminWegener/AMD-fidelityFX-SuperResolution-webGL) based on glea.js Possible ways: 1. Render the scene to a [RenderTargetTexture](https://doc.babylonjs.com/typedoc/classes/BABYLON.RenderTargetTexture), with a lower resolution than the canvas, maybe 1/2 ~ 1/4 2. Use FSR shader to upscale the RenderTargetTexture and render the upscaled result to canvas, instead of rendering the scene to canvas. Questions: 1. Is what described above possible is babylon.js? 2. Are events affected? For example mouse or touch inputs, ray picking, and [GUI](https://doc.babylonjs.com/features/featuresDeepDive/gui). 3. Can [Post Processes](https://doc.babylonjs.com/features/featuresDeepDive/postProcesses) work with this? Or can this be a part of Post Processes? 4. Is this possible with both WebGL and WebGPU engine? 5. Can gpu memory footage reduced with this? 6. Would fps reduce or increase if gpu memory is the bottleneck? 7. How many draw calls would this use in addition to rendering the original scene? 8. Are there anything else affected by this? Possible alternatives: - Intel [XeSS](https://github.com/intel/xess) - AMD [FSR2](https://github.com/GPUOpen-Effects/FidelityFX-FSR2) ---
**Author:** ![sebavan](https://sea2.discourse-cdn.com/flex024/user_avatar/forum.babylonjs.com/sebavan/32/57_2.png) [@sebavan](https://forum.babylonjs.com/u/sebavan)\ **Post date:** [March 24, 2023, 4:54pm UTC](https://forum.babylonjs.com/t/using-amd-fsr-with-babylon-js/39326/2 "2023-03-24T16:54:49Z")
As it seem to be a simple shader pass, it seems totally doable in babylonjs by creating a post process. ---
**Author:** ![kzhsw](https://avatars.discourse-cdn.com/v4/letter/k/848f3c/32.png) [@kzhsw](https://forum.babylonjs.com/u/kzhsw)\ **Post date:** [March 25, 2023, 10:48am UTC](https://forum.babylonjs.com/t/using-amd-fsr-with-babylon-js/39326/3 "2023-03-25T10:48:02Z")
Thx for your reply. Can a post process make the scene rendering to a lower resolution while output as higher resolution? Can gpu memory footage reduced with this? ---
**Author:** ![Evgeni\_Popov](https://sea2.discourse-cdn.com/flex024/user_avatar/forum.babylonjs.com/evgeni_popov/32/4432_2.png) [@Evgeni\_Popov](https://forum.babylonjs.com/u/Evgeni_Popov)\ **Post date:** [March 25, 2023, 1:17pm UTC](https://forum.babylonjs.com/t/using-amd-fsr-with-babylon-js/39326/4 "2023-03-25T13:17:25Z")
You can add a pass-through post-process to render the scene at a reduced resolution, then add the upscaler post-process to generate the final output at the desired resolution. For example, to render to a texture at half the screen resolution: > **[Babylon.js Playground](https://playground.babylonjs.com/#RDSC9U)** > > Babylon.js playground is a live editor for Babylon.js WebGL 3D scenes ---
**Author:** ![jeremy-coleman](https://sea2.discourse-cdn.com/flex024/user_avatar/forum.babylonjs.com/jeremy-coleman/32/15493_2.png) [@jeremy-coleman](https://forum.babylonjs.com/u/jeremy-coleman)\ **Post date:** [March 27, 2023, 11:02pm UTC](https://forum.babylonjs.com/t/using-amd-fsr-with-babylon-js/39326/5 "2023-03-27T23:02:47Z")
theres a bunch of shaders that may be useful here [Anime4K/glsl at master · bloc97/Anime4K · GitHub](https://github.com/bloc97/Anime4K/tree/master/glsl) I linked those specifically because its meant for real time upscaling. Also, i think the nvidia and amd upscalers have some trained models on the hardware drivers which encode scene information as hints into the output image to run through the models. I think the ray tracer denoisers work like this too. So to implement that in babylon, i’d imagine adding some information in vertex attributes that get encoded into the render output, which you then use to train a ML upscaler. Probably not a reasonable goal imo. I think the shader upscaling is not too different than anti aliasing passes. also babylon even has a couple “sharpen” effects that could be a good foundation for this. see [Search Page | Babylon.js Documentation](https://doc.babylonjs.com/search?q=sharpen) . But, the real question is would this provide a benefit? It may be that you are just downsampling the render with the high quality assets still sitting in the gpu memory. It seems like that could cause more overhead not less, could totally be wrong on this though. ---
**Author:** ![vinhui](https://sea2.discourse-cdn.com/flex024/user_avatar/forum.babylonjs.com/vinhui/32/41914_2.png) [@vinhui](https://forum.babylonjs.com/u/vinhui)\ **Post date:** [January 9, 2024, 2:49pm UTC](https://forum.babylonjs.com/t/using-amd-fsr-with-babylon-js/39326/6 "2024-01-09T14:49:41Z")
I decided to implement the shadertoy in babylon, but doesn’t seem to great. Maybe I did something wrong somewhere. > **[Babylon.js Playground](https://playground.babylonjs.com/#IQPJRJ)** > > Babylon.js playground is a live editor for Babylon.js WebGL 3D scenes ---
**Author:** ![sebavan](https://sea2.discourse-cdn.com/flex024/user_avatar/forum.babylonjs.com/sebavan/32/57_2.png) [@sebavan](https://forum.babylonjs.com/u/sebavan)\ **Post date:** [January 9, 2024, 10:07pm UTC](https://forum.babylonjs.com/t/using-amd-fsr-with-babylon-js/39326/7 "2024-01-09T22:07:30Z")
I think a smaller case could help here as it is really hard to tell what goes wrong 🙂 I would suggest rendering directly at 1/4 of the res without fxaa but with MSAA before trying your upscale process.