fsr4-shader-performance-overrides

Makes AMD FSR 4.1.1 upscaling faster on Radeon graphics cards, on Windows and Linux, by replacing FSR 4's slowest shaders with faster ones. One file to swap, nothing else in the game changes.

1. Download the zip for your graphics card.

Not sure which you have? In Windows, open Task Manager, go to Performance and look at the GPU's name; on a laptop with two, the RX one is the one games use.

2. Choose a version. Each zip holds two folders with one file each:

If you are not sure, take exact.

3. Put the file in the game's folder. The game must already run FSR 4.1.1, for example through OptiScaler.

1. Find amd_fidelityfx_upscaler_dx12.dll in the game's folder (often next to OptiScaler) and rename it to amd_fidelityfx_upscaler_dx12.dll.orig. It must be version 4.1.1.2740.
2. Copy the amd_fidelityfx_upscaler_dx12.dll from the folder you chose into its place.

This works on Windows and, under Proton, on Linux. Linux users can instead use one launch option and leave the DLL alone.

4. Check that it worked. Open OptiScaler's overlay in the game. The FSR version reads 4.1.1-cyboman (or 4.1.1-lossy-cyboman; with the other zip 4.1.1-igpu-cyboman or 4.1.1-igpu-lossy-cyboman), and the upscaler time is lower than before.

To undo it, delete the file and rename the .orig file back.

• The gain depends on the output resolution. It is largest at 4K. At 1440p and 1080p the exact DLL's gain depends on the card: some keep most of it (an RX 7900 XT 30% at 1440p, an RX 6600 XT 24% at 1080p), others show little or nothing (the RX 7800 XT and an RX 7900 XTX at 1080p). The lossy DLL helps at every size, because it skips work instead of only doing the same work faster.

• It depends on your graphics chip, too. FSR 4 time saved at 4K, from testers' timing-kit runs and game reports so far:

  Graphics chip	Exact DLL	Lossy DLL
  Radeon RX 7000	15 to 35% in most reports; about 2% in two RX 7800 XT reports	29 to 49%
  Radeon RX 6000	from nothing to about 30%	23 to 48%
  Integrated graphics and handhelds	from a few percent slower to 6% faster	23 to 35%
  Intel Arc B580 (one report)	6 to 8%	31%
  GeForce RTX 3060 Ti (one report)	none	34%

  We do not yet know what decides where a card falls in its range. Most rows rest on a handful of single runs. Results by graphics chip, timing kit results.

• It only shows when the graphics card is the limit. If the processor limits your frame rate, the frame rate does not change.

• The exact DLL cannot change the picture. Its output was compared with AMD's byte for byte at 720p, 1080p, 1440p, 4K and 5K, in still and moving scenes. One intended exception: on RX 6000 cards under Windows, AMD's own file shows ghosting, and the exact DLL carries the fix, so its picture differs from AMD's there.

• The lossy DLL trades a little accuracy for speed. It runs FSR 4's neural network on every other frame and carries its result along with the picture's motion in between. Measured differences and comparison crops: exact and lossy compared. What the alternating cost means for frame caps and V-Sync: frame pacing.

One card, one game, as an example of the best case: a Radeon RX 7800 XT, Shadow of the Tomb Raider's benchmark, 4K output, FSR 4.1.1 Balanced. Your card and your game will give other numbers:

More games and resolutions: all results.

Made-up test scenes on one graphics card, single runs; the previous release's speed is from another run than the other two (2.36 against 2.22 ms there). The comparison page sets this release's lossy DLL beside FSR 3.1, HelixSR and XeSS, with the figures and the scenes it does worst in.

Help test it: the timing kit

Download the Windows timing kit (experimental, 190 MB, version 2026-10-12.6): unpack, double-click fsr4time.exe, wait 15 to 20 minutes. It times FSR 4 with AMD's shaders and with these DLLs on your graphics card, shows which DLLs give the same picture on your machine, and offers to send the result. Reports from Windows are in from eleven graphics chips so far; every further card helps.

• Both kits were updated on 2026-10-12; if you ran an earlier one, please download and run again.
  • Both kits (2026-10-12.6) carry this release's lossy build. The Linux kit now also times the lossy build's first shader on a skipped frame, which this release made cheaper; before, its skipped-frame figure used the exact build's time for that shader.
  • Since the Windows kit 2026-10-12.3: every DLL should give the same picture in both of its runs. Where one does not, the summary now says how different the two are: how many 16x16-pixel blocks, where, and by how much. Two reports from one RX 7800 XT showed such a difference for the lossy DLL at 4K, and this is there to find out what it is.
  • The Windows kit (2026-10-12.2) now shows which part of the exact DLL saves time on your card. It carries two more DLLs: AMD's shaders with only the rewritten last shader, and AMD's shaders with every other rewrite. On some cards under Windows the exact DLL gains a lot and on others almost nothing, and this is how we find out why.
  • It times every DLL twice, in opposite order, and shows both figures where they disagree, so a disturbed reading can be told from a real difference. That makes the run longer than before (seven minutes); the 15 to 20 minutes are an estimate. fsr4time.exe --once gives the short run.
  • It times any FSR 4 DLL you put into a new folder under dlls, not only 4.1.1, and every FSR 4 version that DLL offers.
  • Linux kit 2026-10-12.5: its time for the lossy build's postpass on a skipped frame was too high and is corrected (details in the kit's README). Earlier Linux kit results overstate that one figure and the lossy average.
  • The Linux kit (2026-10-12.6; shorter since 2026-10-12.1): 16 minutes for the full run on an RX 7800 XT, since three tests whose question is settled are gone. It also reports how the card is connected (PCIe link), and when the card is busy it asks you to close what is using it before it starts.
• The Windows kit compares the moving picture as well as the still one.
• New: be named on the thank-you page. When you send your result, the kit asks for a name or nickname to list. It is optional.
• RX 6000 owners: AMD's own shaders show ghosting on these cards under Windows. The kit has two extra reference DLLs and prints a fingerprint of each picture, so your run tells us whether the exact DLL gives the corrected picture there.
• Not only Radeon: the DLLs should run on any graphics chip whose driver supports DirectX 12 with Shader Model 6.6, which includes GeForce and Intel Arc.
• Linux and the Steam Deck: the Linux kit, updated the same day. It now times the lossy build's one changed model pass, and its check that the model passes give AMD's output, blind in kits before 2026-10-10, is fixed.

What the kits do

The technical pages behind this release:

• A prepass in two copies, and a fold in the last shader: where a skipped frame's time went, a rounding difference found on the way, and why three weight words
• Foliage and the network's memory: why moving leaves lag when the network runs on every other frame, what was tried, and the rule for the slow case
• Rain and other thin streaks: why a line passed the rule against single bright pixels, the rule that replaced it, and what it costs thin wires
• Sparkling on glossy surfaces, and a shader that held too much: single over-bright pixels taken for sparks, the test scene, and why a rule that cost nothing in the timing kit cost frames in a game
• Shimmer with auto exposure on: the exposure value's wobble, the store that drops bits, why rounding everything was the wrong fix, and the narrow one that shipped
• The exact files beside a "steady" test build: an unreleased experiment with the dead band of release dll-2026-10-11.4 on the exact files, without frame skip
• Why folding steadied the picture, and what replaced it: the network's weight for the new frame, the one-step flicker, the price in lag, and the dead band
• Bright dots in foliage: why sky seen through leaves was shown as sparks, and the settings that were compared
• A still object over fast ground: why release dll-2026-10-11 left a ghost there, and the two fixes that were tried
• Thin wires, particles and light folds: what erased the wires, the network's own verdict as a signal, and which further layers were folded
• The lossy DLL beside FSR 3.1, HelixSR and XeSS: five upscalers on the same scenes and the same timing, with charts and crops
• Exact and lossy compared: every measurement of the lossy DLL against AMD's, with comparison pictures, and its limits (moving foliage, wires under a slow pan)
• Weight folding: the earlier experiment the light folds come from
• The timing kits: what the Linux and Windows kits measure, and how to read their summaries

Two changes to the lossy DLL. The exact DLL is unchanged.

• The first shader, in two copies. The lossy DLL runs FSR 4's network on every other frame. On the frames in between, the first shader (the "prepass", which prepares the network's input) still did all of its work and then threw most of it away. It now holds its work twice: AMD's code unchanged for the frames that run the network, and a short copy for the frames that skip it, which only records the picture's motion for the last shader.
• A fold in the last shader. The last shader (the "postpass") starts with a small network layer of its own. In each of its 16 outputs the three smallest of 36 groups of weights are merged into their neighbors ("folding"). This does not save time. It makes the last shader lean slightly more on the previous picture where the picture is noisy.
• Found on the way: since dll-2026-10-06.6 the lossy first shader also wrote the motion record on the frames that run the network, and that extra code made the graphics driver's compiler round a few of the shader's other values differently. At some render sizes (seen at 1506x846 and 3012x1694, not at 2260x1272 or 1280x720) those frames therefore did not get exactly AMD's first-shader result: with everything else AMD's, the final picture differed by 0.0001 on average. With two copies they do get it, at all four sizes.

• In a game: Shadow of the Tomb Raider's benchmark at 4K Balanced, one run each on the same day: 18,682 frames and 120 FPS with dll-2026-10-12's Linux files, 18,879 frames and 122 FPS with the two-copy first shader (1% more frames). The overlay's average upscaler time read 2.14 and 2.00 ms. The fold was not in that run; it does not change the amount of work.
• What got worse (all from the fold; dll-2026-10-12 to this release):
  • A flat area at rest changes slightly more per frame: 0.053 to 0.058, and 0.097 to 0.100 with auto exposure on. With AMD's shaders the first figure is 0.126.
  • A thin wire in a slow camera pan is less steady: change per frame 10.34 to 11.04 (AMD's 7.16); with auto exposure on 7.84 to 8.05.
  • Thin vertical detail at rest with auto exposure on: change per frame 0.344 to 0.372.
  • In the scene with glints on a glossy surface, the single brightest stray pixel is 185 levels too bright instead of 91 (AMD's 100). The number of stray pixels there went slightly down (1,462 to 1,419 per million over 20 levels; AMD's 1,460), and with auto exposure on the brightest one reads 142 against 148 before.
  • In the firefly scene, 434 instead of 417 pixels per million are more than 10 levels too bright (AMD's 370).
• What got better besides grain: grain is also closer to the true picture (0.3 to 0.9 dB); a slow brightening shows in a mid-gray flat area 1.20 instead of 1.31 frames late (AMD's 0.89); still foliage has slightly fewer isolated bright dots (1.68 against 1.79 per thousand dark pixels).
• Unchanged or within a few percent: the moving scene at 1080p, 1440p and 4K, 30 to 120 FPS, the ghost and plate scenes, particles, rain, swaying foliage, the still picture's accuracy.
• Why three, and why it is not a dial: two words do almost nothing for grain, three give most of the gain, four a little more at a higher price for the wire, five and six are worse than four again. We measured that and cannot explain it. The result repeats to the third digit over three random grain patterns.
• Not checked:
  • The fold in a game: the benchmark run above had the first change only.
  • Windows drivers, and other graphics chips than the RX 7800 XT. The timings above are from Proton.
  • The quality checks with the HDR option set (the DLLs were compared with the Linux files with it).
• These are single runs on made-up scenes. Where a skipped frame's time went, the rounding difference, and the fold's sweep.

Earlier releases, including dll-2026-10-12 (slowly swaying foliage closer to AMD's), dll-2026-10-11.7 (rain no longer shown as white dashes), dll-2026-10-11.6 (no sparkling on glossy surfaces, a speed loss stopped), dll-2026-10-11.5 (shimmer in bright flat areas with auto exposure on), dll-2026-10-11.3 (fewer bright dots in foliage), dll-2026-10-11.2 (a ghost behind bright objects over fast ground), dll-2026-10-11 (white beads on thin wires, particles closer to AMD's), dll-2026-10-10 (less shimmer on grain and flat areas) and dll-2026-10-09 (particles on skipped frames, two downloads instead of eight): changelog.

You also need a DirectX 12 game in which FSR 4.1.1 already runs, with amd_fidelityfx_upscaler_dx12.dll version 4.1.1.2740.

Both DLLs have AMD's graphics-card check lifted (AMD's own file offers this FSR 4 only on desktop RX 7000 cards), so they start on any card whose driver can run the shaders: DirectX 12 with Shader Model 6.6. That is also why they must not go on an RX 9000 card, where a different FSR 4 would then start as well.

If the first zip is slower than AMD's file on a small RX 6000 card, try the second one: it differs only in one shader that is built smaller. Details: GPU support.

On Linux you can leave AMD's DLL in place and give the game the replacement shaders directly.

1. Download or clone this repository.

2. In Steam, add this to the game's launch options (keep anything already there in front of %command%):

   VKD3D_SHADER_OVERRIDE='Z:/path/to/fsr4-shader-performance-overrides/prebuilt' %command%
   

   Z: is how Proton sees your Linux root, so Z:/home/you/... is /home/you/.... For the lossy version use the folder prebuilt-lossy instead, after reading the WARNING.txt in it.

• The game must be using AMD's original DLL. The launch option does nothing while a DLL from this project is installed, because the files are matched to AMD's shaders.
• The version name does not change with the launch option; OptiScaler shows plain 4.1.1. The upscaler time is how you tell it applied.
• The prebuilt files do not fit every setup. They were made on an RX 7000 desktop card. On one tester's RX 6900 XT, Proton laid the same shaders out differently and the picture came out darker. If the picture looks wrong, build your own files: Linux guide. ./tools/check_prebuilt.sh <dump folder> tells you whether the prebuilt files fit.

If it does not get faster: Linux guide.

Each DLL is AMD's own file with the rewritten shaders swapped in and the version name changed. How that is done, and how to build it yourself: dll/. There is also a ReShade add-on that does the same without touching the DLL: windows/.

The scripts that rewrite the Linux shaders and build the files in prebuilt/ are in tools/ (they were in the top folder until release dll-2026-10-11.3; commands in older posts need tools/ in front).

In some games OptiScaler's upscaler time is only reliable with the frame rate uncapped. If nothing changes at all, check that the game really runs FSR 4.1.1 with AMD's DLL version 4.1.1.2740; other versions have different shaders. See shader variants.

• Nothing else changes. No game files are edited, and the output was compared byte for byte with AMD's at 4K, 1440p and 1080p.
• Game and OptiScaler updates can put the original DLL back; the launch option keeps working.
• Never in online games or games with anti-cheat. This changes the shaders the game renders with, and anti-cheat software can treat that as tampering. Single-player games only.
• Linux: do not set RADV_PERFTEST=cswave32 for a game that runs FSR 4; it adds about 1.1 ms.

The postpass rewrite is adapted from tools/fsr4cap/postpass_lds.py in bbport, a native Linux port of Bloodborne whose author found the slow store pattern and wrote the original rewrite for that project's own FSR 4.1.1 runtime. This repository ports it to the shaders vkd3d-proton generates, so it works in ordinary games.

The scripts are licensed under the GNU GPL v2 or later, like the project they derive from. See LICENSE. The prebuilt shaders are modified versions of AMD's, distributed under the same license together with AMD's notice; see prebuilt/NOTICE.md. Not affiliated with or endorsed by AMD.

Testers who have asked to be named are listed on the thank-you page.

This repository is maintained independently. If this project has provided value to you, and you want to help support the author, consider formalizing your support with a voluntary micro-donation: