An outside developer fixed a ghosting bug in Nvidia's upscaler library, and Nvidia merged it
Nvidia's open render library has been feeding every upscaler it supports a fixed value where a real one belonged, and the person who noticed is not from Nvidia. An outside contributor's pull request against NRI, which holds both of the commits that make the change, was merged into the library's main branch at 11:37 UTC on October 8, read at 21:11 UTC the same day, by the account that maintains it and whose GitHub profile gives its organisation as Nvidia.
Both of NRI's FSR paths carried the hard-coded value, along with its DLSS one. Image: AMD
The value is pre-exposure: the multiplier a renderer has already applied to the colour buffer before it hands that buffer to an upscaler. NRI was passing 1 regardless. In the contributor's own commit message, "Renderers that pre-expose the input color must pass the pre-exposure to the upscaler, otherwise its history is reweighted wrongly when exposure changes (ghosting, brightness lag). FSR (both the FSR 4 SDK and the legacy FSR 3 path) and DLSS hard-coded 1."
Those two named symptoms are the ones players blame upscalers for in general terms: a trail smeared behind a moving object, and a picture that takes a beat too long to settle when the light changes. Here they have a specific cause in a specific place, and the correction runs to a few lines across two files rather than anything inside DLSS or FSR themselves.
The two FSR paths in that sentence are both current code. NRI picked up AMD's FSR 4 SDK on October 6 for Direct3D 12 while keeping the older FidelityFX SDK on Vulkan, so both were carrying the hard-coded value when the correction landed two days later.
A second commit carried it to Intel's upscaler too
The same pull request holds a follow-up the contributor wrote later that morning, at 11:23 UTC. It declares the new field optional, documents it as "the multiplier already applied to the input color", normalises it once so that zero means one, and forwards it to XeSS through xessSetExposureMultiplier, which the contributor notes "applies on top of both the exposure texture and automatic exposure". The library's validation layer now rejects negative values.
One field now reaches all three vendors' upscalers from a single call. Nothing changes for code that does not set it: zero normalises to one, which is what NRI was doing before.
What NRI is, and what this is not
NRI is published by Nvidia as a "Modular extensible low-level render interface (RHI) with higher level extensions". It is the plumbing an engine or a sample uses to talk to Direct3D 12 and Vulkan without writing both twice, and its upscaler extension is where DLSS, FSR and XeSS get wired in behind one interface. XeSS is Intel's, and Intel has separately spelled out when its XeSS frame generation override takes effect. NRI is not a driver, not a game, and not DLSS.
Keep that boundary in view when reading the fix. No shipping game is established as carrying this defect, and none is established as fixed by this change. What the record shows is a hard-coded 1 in Nvidia's own public library, the explanation of why it was wrong written by someone outside the company, and Nvidia's maintainer taking the patch the morning it arrived.
Whoever the contributor is, they had a busy day in the repository. The project's commit history records four merges on October 8, every one of them a pull request from the same account, and the pre-exposure work is only one of them. Nothing on that account's profile gives an employer or any affiliation at all.
