v0.7.2: danielblnc's 0.5.1 supporter build

danielblnc's 0.5.1 supporter build.

• The add-on runs danielblnc's 0.5.1, the newest build he gives his supporters, beside 0.5.0, v0.4.3, v0.4.2 and v0.4.1. Like 0.5.0 it is not distributed, by this project or by the installer: if you have it, the installer takes your own version.dll or dlssnr_on_amd_setup.exe, checks it and patches it for the add-on (by hand: tools/extract_runtime.py and tools/patch_runtime.py, as in the README).
• Its addresses were mapped from 0.5.0 by aligned instructions, one target per field, agree with the OptiScaler fork's own table for it, and pass tools/runtime_offsets_check.py against the patched file.
• Your settings stay. Nothing else changed from v0.7.1.

The installer offers it as an update. Not tested in game; the runtime was driven without a game on an RX 9070 XT (24 of 24 frames per wait mode, no timeout). Full notes in CHANGELOG.md.

v0.7.1: motion by optical flow, no more fading and flicker while the camera moves

Motion measured by optical flow wherever a game gives none.

Fixes the effect fading and flickering while the camera moves, on D3D12, Vulkan and OpenGL games and on D3D11 games
that render no velocity buffer.

• The motion is now measured by AMD FidelityFX optical flow instead of the add-on's block estimator. On a textured
  scene the estimator turned a camera pan into noise, the runtime threw its history away, and the effect faded and
  flickered while the camera moved and came back once it stopped. On a synthetic textured pan the motion error drops
  from 19.8 px to 0.19 px (median) and the output's frame-to-frame change by 60%. A game's own vectors and the
  companion effect still come first, and OpticalFlow=0 in amd-nr.ini goes back to the estimator.
• Each block's vector follows the depth, so a character's motion no longer bleeds onto the background behind it.
• Your settings stay. An amd-nr.ini you already have keeps everything in it.
• If the picture shimmers in motion, bring Intensity and Structure back towards 1 first: very high values multiply
  whatever the network does from one frame to the next.
• Known: on a still picture with heavy noise or dithering the optical flow can read a pixel or two of motion that is
  not there. A fix is being worked on.
• Cost: roughly half a millisecond per frame at 1080p on an RX 9070 XT.
• 32-bit games are unchanged and keep the estimator. Same runtimes as v0.7.0: v0.4.3, v0.4.2 and v0.4.1, and the 0.5.0
  supporter build from your own files.

AMD-NR ReShade Installer v0.6.7 offers it as an update; no new installer is needed. Tested in game on the D3D12 route.
Full notes in CHANGELOG.md.

v0.7.0: DLSS-NR-on-AMD v0.4.3, steadier by default, and fewer ways to crash

DLSS-NR-on-AMD v0.4.3, steadier by default, Passes that apply live, and a long list of fixes.

The add-on moves to danielblnc's runtime v0.4.3 (upstream: 20% faster than v0.4.2 in Reference quality, 18% in
Fast, the default) and still runs v0.4.2 and v0.4.1. It also runs his 0.5.0 supporter build, which is not
distributed: if you have it, you supply your own file and the installer checks and patches it for you. The weights are
unchanged. On 32-bit games, amd-nr.addon32 and amd-nr-host64.exe go together (bridge protocol v5); the
installer updates both.

• New: Fixed seed and Output smoothing, on by default together with Temporal On. The steadiest set measured on
  recorded play. An amd-nr.ini from an earlier release at Temporal=0, the default then, moves to Temporal On once,
  and the log says so. To go back: Temporal to Auto, untick Fixed seed, Output smoothing off.
• Emulators come back on their own. Switching game or renderer (D3D11, Vulkan, OpenGL) no longer needs a restart:
  the add-on follows the new device. D3D12 still asks for one.
• Network precision in the panel (Engine, under More settings) on runtime v0.4.2, v0.4.3 and 0.5.0: Fast (the
  default) or Reference, NVIDIA's exact arithmetic. It applies at once.
• Passes applies live, in both directions. Each extra pass loads its own copy of the runtime (about 150 MB of VRAM)
  the first time it is needed, which costs one long frame.
• D3D12 games: every frame gets the effect. Up to 85% of the frames used to go out untouched, a strobe. The frame
  rate now follows the network, so lower Scale for more fps.
• Lighting no longer flickers where a game's motion buffer is not really motion, and 32-bit games with 2 or 3
  passes no longer blink. Depth a game clears before present is copied before the clear, and depth that reads as junk
  is no longer handed to the network.
• The runtime gets the whole packet it reads: 16 bytes it read past the end, a jitter pair among them, came from
  the stack. They are zero now.
• Crashes and hangs: a game that destroys or loses its device, a GPU wait that never ends, a network that keeps
  overrunning, a slow frame on a 32-bit game, OpenGL fences that do not work, a second window, and Vulkan on a machine
  with two GPUs are all handled now. The game carries on, and when the effect has to switch off the panel says why.
• Removed: Async timing on 64-bit games, which only ran the effect about twice a second (the 32-bit Timing stays),
  and GlHoldFrames on OpenGL. The panel now offers only the controls each API can use.

Released together with AMD-NR-ReShade-Installer v0.6.7. Tested in game on the Vulkan route (RPCS3) with the patched v0.4.3. The full list is in
CHANGELOG.md.

v0.6.9: DLSS-NR-on-AMD v0.4.1

DLSS-NR-on-AMD v0.4.1, and the runtime in the panel.

The add-on now runs danielblnc's runtime v0.4.1. Upstream moved the network to a high-priority GPU queue and measures it 8% faster than v0.4.0, and 9% more under heavy load. The weights did not change, so an upgrade replaces one DLL and downloads nothing else.

AMD-NR-ReShade-Installer v0.6.3 moves to this release and to the patched v0.4.1 runtime in the same step. Update through the installer. This add-on refuses the v0.4.0 runtime, and the panel says which one it needs.

• Every address was mapped again. v0.4.1 moved the runtime's data. Each address was derived twice, independently, and agrees with the OptiScaler fork's own map. On our 960x540 test frame the output is byte-identical to v0.4.0.
• The status column shows the runtime and what it costs, for example "danielblnc 0.4.1: network 13.3 ms". That is the network's GPU time for the last frame, every pass added up, read from the runtime itself.
• 32-bit games show it too, for danielblnc and for mochizuki, which v0.6.8 left out of the 32-bit panel. The bridge protocol is v4: amd-nr.addon32 and amd-nr-host64.exe from this release go together. The installer updates both.

Tested in Euro Truck Simulator 2 (64-bit) and GTA IV (32-bit). The full list is in CHANGELOG.md.

v0.6.8: the mochizuki runtime

A second runtime: mochizuki, picked in the panel.

The add-on can now run the network through mochizuki, mochizuki0323's Vulkan port of the same NVIDIA network (DLSSNR-AMD), as the OptiScaler AMD NR fork builds it. danielblnc's runtime stays the default and is unchanged.

AMD-NR-ReShade-Installer v0.6.2 pins this release. Tick mochizuki in a game's sheet and it installs MochizukiNrRuntime.dll and its dlssnr-amd\ folder beside the add-on (RDNA4 cards only, about 141 MB). Untick it and the next install takes them out.

• NR runtime, under Language in the panel, picks danielblnc (HIP) or mochizuki (Vulkan). It is saved to amd-nr.ini as NrBackend and applies when the game is started again. It works on the 64-bit route and on the 32-bit bridge.
• mochizuki runs only on RDNA4 (RX 9000 series). The first start in each game builds its network, which takes up to a minute; frames go out untouched until then. Its log is mochizuki_nr.log.
• Scale, Passes, Structure, Tone, Skin, the character mask, the per-pass profiles and every compose control (Intensity, Limit, Colour Strength, the grade) apply to it. The Engine controls that write into danielblnc's runtime do not.
• Its picture is not danielblnc's. On our 960x540 test frame the mean correction is the same size (0.029 against 0.030) with a different structure, and it brings a colour cast of its own that Colour Strength 0 takes back to the game's hue. That setting matches the OptiScaler fork's default for this runtime.
• Cost on an RX 9070 XT at 960x540: 6.8 ms for one pass, 11.7 ms for two, 17.3 ms for three.
• If amd-nr.ini names mochizuki and its files are not there, the add-on runs danielblnc and the panel says mochizuki is not installed.
• Export logs now takes mochizuki_nr.log too.

Approved after an in-game try in Euro Truck Simulator 2 (D3D11). The full list is in CHANGELOG.md.

v0.6.7 - DLSS-NR-on-AMD v0.4.0

DLSS-NR-on-AMD v0.4.0: the runtime is faster, and every game gets it through the installer.

The add-on now runs danielblnc's runtime v0.4.0. In our test, a 960x540 synthetic frame on an RX 9070 XT, a frame took 8.9 ms, against 15.5 ms on v0.3.0. Upstream measures v0.4.0 as 42% faster than v0.3.3. The weights did not change, so an upgrade replaces one DLL and downloads nothing else.

AMD-NR-ReShade-Installer v0.6.1 moves to this release and to the patched v0.4.0 runtime in the same step. Update through the installer. This add-on refuses the old v0.3.0 runtime and says "a different build" in the panel.

• Every address moved. v0.4.0 relocated the runtime's data, and every v0.3.0 address now lands in read-only memory. All of them were re-derived twice, independently, and agree with the OptiScaler fork's own map of the same runtime.
• The system d3d12.dll stays out of D3D11, Vulkan, OpenGL and 32-bit games. The new runtime loads d3d12 late, which the add-on's private copy did not cover. That would have brought back the NFS 2015 resize crash.
• New runtime options are pinned. Style, ToneCurve and ToneLift are fixed to what v0.3.0 did, and CpuWait to 0, so an ini left in the game folder cannot change the picture or stall the present.
• The picture is not identical to v0.3.0. With the same settings, the network's change is 15-24% stronger on the synthetic frame. It was compared in game (GTA IV) before this release and approved.
• Fixes that were waiting since v0.6.6:
  • a 32-bit D3D9 game no longer crashes on exit;
  • a resolution change in Async mode no longer turns the effect off;
  • a resize no longer clears the game's D3D11 state (PCSX2);
  • Factory Defaults is on the 64-bit panel too.

The full list is in CHANGELOG.md.

v0.6.6 - The 32-bit panel is the rebuilt one

32-bit games get the new panel. The image was already the new one; the menu was not.

v0.6.5 rebuilt the panel — 47 controls down to 15, the status column, More settings — and the rebuild landed on the 64-bit route only. Every 32-bit game (D3D8, D3D9, D3D11 — Castle Crashers, Bully, GTA IV) kept the old forty-control menu with the MEASURED / TRACED / UNKNOWN / INERT tags on it.

The backend there was never old. The helper compiles the same engine, so the bounded-ratio composition has been running on 32-bit since v0.6.5, and the bridge already carried Highlight Guard, Colour Strength, Residual Limit, Edge Fade, Intensity, Structure, Skin and Scale. Only the panel could not reach them. If you play a 32-bit game, the controls that the last release was about are on screen now.

Same fifteen controls, same wording, same cascade as the 64-bit panel, so a person who plays both does not have to learn the overlay twice. Three things stay different on this route, because the route is different:

• Timing switches the bridge's pipelining, not the engine's inline mode — inside the helper the network always runs in the same frame.
• Save, Reload, Factory Defaults and Measure residual are requests posted to the helper, because the ini and the engine live in the other process.
• Use Feed.fx has no row: the companion effect is read through ReShade's effect runtime, which is in the game's process, while the network is in the helper. There is nothing there for the switch to reach.

Also in this release

• Export logs to desktop, the button the 64-bit panel got, now on this route too — and it collects both logs, from both folders: the add-on writes beside itself, the helper writes beside the game.
• The helper reports its scale cap. When one evaluation takes long enough to risk the display driver, the helper lowers the scale on its own. The panel now compares the network raster against what is really running instead of against the slider, so a capped-but-working configuration stops reading as "not applied yet". Move the slider to ask for the full scale again.
• A fresh 32-bit ini no longer writes Skin=1. -1 is the engine's automatic and the value it boots with; writing 1 switched that off before anybody had touched a control — the same bug the 64-bit default had until v0.6.5. Factory Defaults restores -1 too, and leaves your panel arrangement alone: which controls are on screen is a preference, like the language and the hotkey.
• Bridge protocol v3. Style, StyleStrength, HiddenShown, DepthInverted and DepthNormalise cross the bridge now. The pair is built and shipped together and a mismatched pair is refused at the header, so update amd-nr.addon32 and amd-nr-host64.exe together — the installer does that for you.

The 64-bit add-on is unchanged

amd-nr.addon64 is the v0.6.5 binary, same hash, attached here so the release is complete. Same pinned DLSS-NR-on-AMD v0.3.0 runtime and the same weights. If you only play 64-bit games there is nothing here for you.

v0.6.5 - Pass Count fixed, and a new name

Pass Count finally works. 2 and 3 passes don't look weird and splotchy anymore.

The add-on used to add the network's correction to the frame, channel by channel, and clip whatever left the range — and a clipped channel is a hue rotation, not more detail. Two passes meant twice the difference and three meant three times it, so the count read as blotches and saturation instead of sharpness. Multipass was a trap.

The answer is now turned into a picture of its own, its luminance compared against the frame's as a bounded ratio, and two finished pictures blended. A bounded ratio cannot move hue, by construction. This is what the OptiScaler DLSS-NR fork does and what RenoDX's addon did before it.

Four controls fall out of the new composition:

• Colour Strength — at 0 every pixel keeps the game's own hue and only its brightness carries what the network decided. This is the answer to "it changed the colours of my game": at 0 it cannot, by construction.
• Highlight Guard — the most compose may move a pixel, as a multiple of what it already was. 2.0x, which is what 254 composition lines across seven games and nine RTX machines all read.
• Residual Limit — the blown-blocks control. A measured two-pass run came back with a mean correction of 0.072 and a maximum of 4.16, in a picture whose own mean is 0.13. That is a tile where the network extrapolated rather than saw, and every extra pass used to pile onto it.
• Edge Fade — border tiles have no neighbour on one side, so what comes back there is invented. A corner sits in two bands at once, which is why the corners went first.

Plus bicubic residual upsample: below full Resolution Scale only the correction comes back up, and stretching it bilinearly threw away everything but colour and brightness — which alone made the whole effect look like a colour filter.

The project is now AMD Neural Rendering

We are stepping away from "DLSS5" and calling this what it is: neural rendering on AMD. Tying the project to another vendor's version number was always going to age badly, and this way it can outlive whatever that number does next.

Everything we own was renamed — amd-nr.addon64, amd-nr.ini, amd-nr.log, AMD_Neural_Feed.fx, and ReShade's Add-ons tab now reads AMD Neural Rendering. Nothing belonging to anyone else moved: the runtime is still dlssnr_amd_pass1.dll, and the upstream port is still DLSS-NR-on-AMD by danielblnc, which this add-on drives rather than reimplements. Your existing dlss5-neural.ini is carried over on first run and the old file is left where it is. The repository keeps its URL so existing links keep working.

NR Preset vs NR Style, and which one we actually got

These are two different things and they keep getting mixed up.

NR Preset (DLSSNR.Hint.Render.Preset) is a hint asking for a different set of weights. The shipping DLL carries exactly one set; its own log says 1 config(s) available, and every other value falls back to it. It does nothing here and it does nothing on NVIDIA either. Closed, on both sides.

NR Style (DLSSNR.Style) is the A / B / C models, and on NVIDIA it is two things at once: an input fed into the network — which is what actually moves lighting and detail — and a colour grade applied to the finished frame.

We got the grade. We did not get the network input. This is a partial port and we are not going to pretend otherwise: the conditioning vector the network reads lives only in the GPU's local memory, where nothing outside the kernel can reach it — no hook, no side kernel, no shared buffer. That was measured, not assumed. So A/B/C here are a colour difference rather than a detail difference, which is why they sit under Experimental with a work-in-progress warning. The grade half is at least correct: constants read out of nvngx_dlssnr.dll and verified against its SASS. RenoDX calls them Model A/B/C, Deep Fried Chicken calls them Default/Natural/Cinematic; the panel prints both.

Real motion vectors, from a shader you already have

AMD_Neural_Feed.fx hands the add-on a real optical-flow field from iMMERSE Launchpad, VORT or LumeniteFX, plus ReShade's own depth buffer. None of them is bundled or included. This matters most on an emulator, where the console never computed per-pixel motion and the only alternative is the built-in estimator: two levels of block matching at radius four, because it shares the frame with the network. Launchpad runs eight. A game with its own velocity buffer still beats both, and the overlay says which one is actually feeding the network.

The overlay, rebuilt

47 controls across eight headers became 15, built for a narrow panel — kept thin so the game stays visible behind it.

• Nothing was removed, only taken off screen. A hidden control still reads and writes its own key in amd-nr.ini. More settings at the bottom opens a cascade with a checkbox per hidden control, grouped under the header it will appear beneath.
• Status moved to the right-hand column, opposite the switches. Left is what you change, right is what happened.
• Colour means something now. The old panel painted Timing, Scale and Passes amber the moment Scale passed 0.50 or Passes passed 1 — most of a working configuration, and amber that is on while everything is fine is amber nobody reads. Red is the documented device-removal path and nothing else; amber comes from the measured skip rate or from the card's own cap having fired.
• Export logs to desktop — one button puts the add-on's log, the runtime's log, ReShade's log and your ini in a dated folder on the desktop.

Three controls that were broken

• Skin Structure shipped at 1.0, writing over the -1 the engine boots with — and -1 means automatic. The add-on turned that off before you touched anything, while the help text described it in the past tense. It is -1 again, and a checkbox now, because a mode does not belong on a -1..3 slider where everything between -1 and 0 meant nothing.
• Tone Channels had four positions and two meanings. The record path writes (value & ~2) | 4, so position 2 was byte for byte identical to 0, and 3 to 1.
• DepthNormalise shipped on while the overlay painted it amber and its own help text said it reads as the wrong operation on this bench. It ships off.

Also

Weight parity proven: 153 tensors, byte for byte identical to nvngx_dlssnr.dll — the network is NVIDIA's, so any difference against an RTX machine is in the composition, the controls or the fp8 arithmetic, never in the model. Per-pass profiles, with Local Tone reaching the first pass only. The engine's option struct mapped by decompiling its ini reader rather than guessed, which is where Temporal came from — the byte this project had labelled "motion is valid", wrongly.

Same pinned DLSS-NR-on-AMD v0.3.0 runtime and the same weights, so the upgrade is the add-on and the effect.

Upgrading

The installer does this for you and its auto-updater will offer it. By hand: delete dlss5-neural.addon64, drop amd-nr.addon64 in, and put AMD_Neural_Feed.fx in your reshade-shaders\Shaders folder. Two things a rename cannot migrate — a ReShade preset naming the old effect has to be re-enabled against AMD_Neural_Feed.fx, and the AMDNR_MV_PROVIDER preprocessor definition starts again at its default of Launchpad.

v0.6.0 - OpenGL

Adds an OpenGL route. The network runs where it always runs — this add-on's own private D3D12 device — and the frame crosses to it through GL_EXT_memory_object_win32, with the shared textures created on our device and imported into the host. Validated end to end on Luanti 5.17.0 with the network running.

• Colour and estimated motion, no depth from the game, the same as Vulkan.
• The hand-over runs on the GPU through the imported D3D12 fences, so this is the only route that does not stall the CPU twice a frame. GlSemaphores=0 in the ini forces the old behaviour.
• Every frame that reaches the screen has been through the network: where the previous evaluation is still running the route waits rather than letting an uncorrected frame past. GlHoldFrames=N repeats the last result instead, off by default.
• A multisampled default framebuffer is resolved on the way in.
• 32-bit OpenGL games have no route — the 32-bit pair covers D3D8, D3D9 and D3D11.

Same pinned DLSS-NR-on-AMD v0.3.0 runtime and the same weights as v0.5.x, so an upgrade is this one file.

Two new diagnostics, neither needing a game: glprobe asks the driver whether the crossing is possible at all, glinfo reports what ReShade hands an add-on inside a real OpenGL host. What was measured, and what it cost to learn, is in docs/opengl-route.md; the full list is in the changelog.

v0.5.3 - The 32-bit bridge is faster

This uses the same DLSS-NR-on-AMD v0.3.0 runtime and the same weights as
v0.5.2. The 141 MB download does not change.

This release only changes the 32-bit bridge. Two files are new:
dlss5-neural.addon32 and dlss5-neural-host64.exe. Nothing changes for 64-bit
games. dlss5-neural.addon64 is the same file as in v0.5.2.

The bridge no longer waits for the helper

The bridge used to wait for the helper inside Present. That added the network
cost to every frame.

It now sends the frame and does not wait. It draws the answer to the previous
frame instead. The helper does its work while the game builds the next frame.

Here is what that measured. Only the setting was changed between runs, and
each pair used the same scene:

GTA IV 43.8 -> 61.6 FPS
Resident Evil 5 46.6 -> 62.2 FPS (using the game's own benchmark)
Half-Life 2 77.0 -> 89.3 FPS

How much you gain depends on the game. The most it can save is the smaller of
two numbers: how long the game takes on its own, and how long the network
takes. Some games were already overlapping part of that. Those gain less.

The cost is one frame of delay. The image does not change. The whole back
buffer is replaced, so you see the previous frame finished. You do not see a
mix of two frames. All three games were checked with the setting on and off
and looked the same.

This is on by default. To turn it off, set Async=0 under [dlss5] in
dlss5-neural.ini. You can also change it in the overlay under Timing while the
game is running. The overlay saves your choice.

The timing probe can be turned on in the ini

Other changes

The add-on now handles destroy_device. This is for games that close without
telling ReShade to destroy the swapchain.

This does not stop the "Reference count is inconsistent" warning that ReShade
writes when a game closes. Nothing in an add-on can stop it. ReShade does not
send that event on this path, and it writes the warning two seconds before it
unloads the add-on. The warning is harmless. It is written while the game is
closing. The handler is kept because it is correct for games that close
properly.

Game names were removed from comments in the bridge source. A test blocks
them, because the bridge does not have per-game settings. The numbers are in
the handoff document.
Título da release

v0.5.3 - The 32-bit bridge is faster

Descrição

This uses the same DLSS-NR-on-AMD v0.3.0 runtime and the same weights as
v0.5.2. The 141 MB download does not change.

This release only changes the 32-bit bridge. Two files are new:
dlss5-neural.addon32 and dlss5-neural-host64.exe. Nothing changes for 64-bit
games. dlss5-neural.addon64 is the same file as in v0.5.2.

The bridge no longer waits for the helper

The bridge used to wait for the helper inside Present. That added the network
cost to every frame.

It now sends the frame and does not wait. It draws the answer to the previous
frame instead. The helper does its work while the game builds the next frame.

Here is what that measured. Only the setting was changed between runs, and
each pair used the same scene:

GTA IV 43.8 -> 61.6 FPS
Resident Evil 5 46.6 -> 62.2 FPS (using the game's own benchmark)
Half-Life 2 77.0 -> 89.3 FPS

How much you gain depends on the game. The most it can save is the smaller of
two numbers: how long the game takes on its own, and how long the network
takes. Some games were already overlapping part of that. Those gain less.

The cost is one frame of delay. The image does not change. The whole back
buffer is replaced, so you see the previous frame finished. You do not see a
mix of two frames. All three games were checked with the setting on and off
and looked the same.

This is on by default. To turn it off, set Async=0 under [dlss5] in
dlss5-neural.ini. You can also change it in the overlay under Timing while the
game is running. The overlay saves your choice.

The timing probe can be turned on in the ini

Set Timing=1 under [dlss5] in dlss5-neural.ini.

Before this, the probe only read an environment variable. Some games restart
themselves through their own launcher. Those games do not inherit the
variable, so the probe never turned on. GTA IV is one of them.

The probe also measures how long each frame takes now. Every probe line says
which mode it measured and whether the effect was on.

Other changes

The add-on now handles destroy_device. This is for games that close without
telling ReShade to destroy the swapchain.

This does not stop the "Reference count is inconsistent" warning that ReShade
writes when a game closes. Nothing in an add-on can stop it. ReShade does not
send that event on this path, and it writes the warning two seconds before it
unloads the add-on. The warning is harmless. It is written while the game is
closing. The handler is kept because it is correct for games that close
properly.
unloads the add-on. The warning is harmless. It is written while the game is
closing. The handler is kept because it is correct for games that close
properly.

Game names were removed from comments in the bridge source. A test blocks
them, because the bridge does not have per-game settings. The numbers are in
the handoff document.