The FSR SDK lists eight techniques and a separate SDK version

Eight techniques, eight version numbers, one repository

The README's central table is where the SDK makes sense, and the detail that catches people out is that the SDK version and the technique versions are numbered separately. The repository is at SDK 2.3.0, codenamed Redstone, while the techniques inside it sit at their own numbers:

- Super Resolution (Temporal) at 2.3.4 - Super Resolution (Upscaler) at 3.1.5 - Upscaling (ML-Upscaler) at 4.1.1 - Frame Generation at 3.1.6 - Frame Generation SwapChain at 3.1.7 - Frame Generation (ML) at 4.0.1 - Ray Regeneration (ML-Denoiser) at 1.2.0 - Radiance Caching, marked Preview, with no version number

So bumping the SDK to 2.3.0 does not mean every technique moved to a matching number. If you pin a technique, you are pinning a line that is developed independently inside the same repository, and the SDK tag is a packaging decision on top.

Three of these are temporal upscalers producing high resolution frames from lower resolution inputs, and two of them are frame generators producing interpolated frames from multiple real input frames plus motion vector data. The SwapChain entry is a different animal entirely: a replacement DXGI Swapchain implementation for DX12 that presents additional frames alongside real game frames with relevant frame pacing.

The repository splits into Kits, Samples, Tools and docs

The top level is small and legible: `Kits/`, `Samples/`, `Tools/`, `docs/`, `3rdpartynotice.md`, `readme.md`, and two Windows batch files, `ClearMediaCache.bat` and `UpdateMedia.bat`.

`Kits/` holds the shipped technique libraries themselves, with each technique's documentation living beside its code under paths like `Kits/FidelityFX/docs/techniques/super-resolution-temporal.md`. That layout means a technique's markdown and its source stay together, which is convenient when you are reading one technique rather than the whole SDK.

`Samples/` is the other half and is divided by category rather than by technique: `Samples/Upscalers/`, `Samples/Denoisers/` and `Samples/RadianceCaches/` are the directories in the repository. Note that the categorization does not mirror the technique list one to one, because several techniques share a sample. The README points the upscaling, upscaler, ML-Upscaler, both frame generators and the SwapChain all at the same AMD FSR Upscaling and Frame Generation Sample, with only Ray Regeneration and Radiance Caching having their own samples.

The build documentation is separate again, under `docs/getting-started/`, which holds `sdk-structure.md`, `building-samples.md` and `running-samples.md`. There is a tools page too, for the AMD FSR SDK Media Delivery System at `docs/tools/media-delivery.md`.

Getting the samples onto your machine

The README does not carry build commands itself. It routes you to `docs/getting-started/building-samples.md` for compilation and `docs/getting-started/running-samples.md` for launching them, and to `docs/getting-started/sdk-structure.md` for how the tree fits together. Clone the repository and read those three pages before anything else, because the Windows path issue below will bite you during that first build.

Two batch files at the repository root are worth knowing about. `UpdateMedia.bat` fetches the media assets the samples need, which is why the repository ships them as a separate step rather than as part of a clone. `ClearMediaCache.bat` clears the cached copy of that media, which is the first thing to try if a sample fails to find its textures after a fresh update.

There is no Linux or macOS path documented in the README. Combined with the Windows-specific batch scripts and the DXGI Swapchain technique, the evidence points at a Windows first project, though the README does not state an explicit platform support matrix. Confirm that before planning an evaluation on a Linux build agent.

The samples are stated to be open source under the MIT license, with terms in `docs/license.md`. Note that the repository's own licence field is not recorded, and that the MIT statement covers the samples; third party components are listed separately in `3rdpartynotice.md`.

Vulkan is listed as unsupported, and path length is a first build failure

The known issues table has two rows and both matter.

The first applies to every sample on every API and every configuration: Windows path length restrictions may cause compile issues, and the recommendation is to place the SDK close to the root of a drive, or to use subst or a mklink to shorten the path. The table documents the path-length problem and recommends placing the SDK near a drive root or using subst or a mklink to shorten the path.

The second row is more consequential: Vulkan is currently not supported in the SDK, across all configurations. That sits awkwardly with the README's opening sentence, which describes the SDK as technologies for DirectX 12 or Vulkan applications. The marketing framing and the known issues table disagree, and for an engineer the table is the operative statement. If your renderer is Vulkan, this SDK is not the answer, and no amount of build configuration changes that.

On the plus side, the temporal upscalers are software techniques running on the GPU, so they do not require hardware from any particular vendor. That is the point of FSR as distinct from vendor-specific upscaling, and it is the reason to evaluate it even on a non-AMD GPU.

ML techniques are a separate decision from the temporal ones

The SDK now contains two machine learning based entries, ML-Upscaler at 4.1.1 and Frame Generation (ML) at 4.0.1, plus Ray Regeneration (ML-Denoiser) at 1.2.0 for denoising, while Radiance Caching in preview is for path tracing result caching. The table mixes upscaling, frame generation, denoising and path tracing result caching.

The practical difference from the temporal techniques is deployment. The temporal and SwapChain entries are ordinary graphics code operating on colour and motion vector data. The ML ones require model assets and inference, and the repository's separate media step is the clue that assets travel separately from source. If you are evaluating this SDK, the ML entries change your content pipeline, your build size and your platform support surface, and the README does not enumerate which runtimes they depend on. Read `Kits/FidelityFX/docs/techniques/super-resolution-ml.md` and `frame-interpolation-ml.md` for that rather than assuming the temporal samples cover it.

Radiance Caching being labelled Preview is the honest signal here. Preview means the interface may change, and it is the entry to approach last.

Release history, version notes, and the licensing picture

Three releases are visible in the recent history: FSR SDK 2.3.0 on 2026-06-24, 2.2.0 on 2026-03-23, and 2.1.1 on 2026-02-23. The last push to the repository was on 2026-06-24, the same day as the 2.3.0 tag, and the repository is not archived.

Per version change notes live under `Kits/FidelityFX/docs/whats-new/`, with a page per SDK release going back to 1.0, including the 1.0.x and 1.1.x point releases. The 2.3.0 and 2.2.0 entries both point at the same index page rather than separate files, so the newest releases are documented together. When you upgrade, that page is where you find out which technique versions moved and which did not.

On licensing, three things sit next to each other and are easy to conflate. The samples are MIT, with the README saying so directly and pointing to `docs/license.md` for the terms. Third party components are accounted for in `3rdpartynotice.md` at the root, which you need for a compliance review of any bundled library. And the AMD, Radeon, Ryzen, CrossFire and RDNA names are trademarks, so an MIT grant on the code does not let you name your product after them.

Editorial conclusion

Consider the FSR SDK if your engine is DirectX 12 based and you want temporal upscaling. Skip it for a Vulkan title, because the README's known issues table states Vulkan is not supported in the SDK, and skip it if you cannot live with MIT-licensed samples carrying AMD trademark names. Before integrating, clone the repository, read docs/getting-started/sdk-structure.md, and confirm the technique version you are targeting against Kits/FidelityFX/docs/whats-new/index.md, since the SDK tag and the technique version do not move together.

Frequently asked questions

Official sources

1. GPUOpen-LibrariesAndSDKs/FidelityFX-SDK on GitHub
2. Issues
3. README
4. Releases