AMD FSR Redstone SDK 2.1: ML Frame Gen and Ray Denoising on RDNA4

  • Thread Author
AMD has shipped FSR Redstone as part of the new AMD FSR SDK 2.1 and bundled Redstone feature support into the Adrenalin 25.12.1 driver — a significant step that replaces large parts of the old FidelityFX naming, brings machine‑learning‑driven frame generation, ray denoising and an online radiance cache to AMD’s graphics stack, and yet arrives with strict hardware and OS constraints that will shape adoption in 2026 and beyond.

AMD RDNA 4 chip on a blue circuit board, with Frame Generation and Radiance Caching panels, Windows 11 logo.Background​

AMD’s FSR Redstone is the most ambitious iteration yet of the FSR line: no longer just a resolution upscaler, Redstone is a suite of ML‑first tools designed to reduce ray‑tracing costs, generate intermediate frames, and produce higher‑quality upscales when paired with on‑device machine learning accelerators in RDNA4 (Radeon RX 9000 series) GPUs. The company released the developer pieces as AMD FSR SDK 2.1 and exposed a user‑facing launch path via Adrenalin 25.12.1 for Windows systems — a combination intended to let developers integrate Redstone directly while also giving players driver‑level toggles for supported games. FSR Redstone is notable for three headline technologies:
  • FSR Frame Generation, a neural temporal interpolator that produces intermediate frames from two consecutive source images to multiply perceived framerate.
  • FSR Ray Regeneration, a neural denoiser / ray reconstruction system that cleans noisy ray‑traced samples at far lower sample counts.
  • FSR Radiance Caching, an online, continuously‑trained learned cache for multi‑bounce global illumination that aims to accelerate Monte Carlo path tracing without precomputation.
Those features are architected around the dedicated ML pipelines available on AMD’s RDNA4 silicon and are delivered to developers through the FSR SDK 2.1.

Overview: what AMD shipped and what it means​

The product components​

AMD’s December rollout is threefold:
  • FSR SDK 2.1 — Developer libraries, runtime hooks, and sample models for Redstone features intended for engine and middleware integration.
  • Adrenalin 25.12.1 — A WHQL Windows driver release that exposes a driver‑level toggle and per‑title support for Redstone features where games already integrate FSR hooks or where the driver can apply fallbacks.
  • Marketing / branding consolidation — AMD is collapsing the legacy “FidelityFX” subbrands under a single AMD FSR umbrella to reduce naming complexity and to align all upscaling, frame generation and ray‑assist tooling under one consistent developer story.

What the SDK emphasizes for developers​

The SDK focuses on modularity and developer control: components are designed to plug into a variety of engines, with runtime models and training configurations provided as starting points. AMD’s intent is clear — make the integration as straightforward as possible while giving studios engine‑level control over quality/performance tradeoffs. The SDK also documents fallback and analytical paths so titles can ship broader compatibility across older GPUs, but the most powerful ML modes require RDNA4 hardware.

Deep dive: the Redstone features​

AMD FSR Frame Generation​

What it does: Frame Generation uses a neural model to interpolate motion between two rendered frames and produce one or more synthetic intermediate frames. Unlike simple analytical motion interpolation, Redstone’s approach aims to minimize common artifacts such as ghosting, motion discontinuities and temporal instability. The net result is higher apparent framerates without rendering every native frame.
Why it matters: Properly implemented, ML frame generation can transform 60 fps output into something visually close to 120 fps with only a modest increase in latency when paired with system‑side latency mitigation (render queue management, micro‑stutters smoothing). At launch the driver’s frame‑gen works as a drop‑in for titles that already support the FSR 3.x‑era frame generation toggle, so early game support is primarily enabled via driver‑side application rather than per‑title native Redstone hooks.

AMD FSR Ray Regeneration​

What it does: Ray Regeneration is a neural denoiser and ray‑reconstruction stage that operates on ray‑traced outputs (sparse samples, low‑sample path tracing) and reconstructs coherent, lower‑noise images than traditional analytical denoisers can produce at the same sample counts. In practice it reduces the number of expensive ray samples required for acceptable image quality.
Current availability and examples: Ray Regeneration is already shipping in one high‑profile game (Call of Duty: Black Ops 7) as AMD and Activision co‑engineered the integration; broader game support requires developers to call into the SDK or expose driver toggles. Because Ray Regeneration is tightly coupled to RDNA4 ML accelerators, its top‑tier modes need RX 9000 series hardware.

AMD FSR Radiance Caching​

What it does: Radiance Caching is an online ML model that learns multi‑bounce indirect illumination behavior in real time and stores illumination contributions in a compact cache. The model continuously adapts to scene changes and removes the need for offline baking or heavy per‑frame global illumination tracing once it has stabilized.
Where it sits in the pipeline: Radiance Caching is intended to pair with Monte Carlo path tracing to reduce the per‑frame workload for indirect lighting. AMD notes that this system is expected to be most effective when used with RDNA4 accelerators and when combined with Ray Regeneration and ML upscaling for a full Redstone effect.
Delivery timeline caveat: Radiance Caching was announced as part of Redstone but some publishers and reviewers indicate parts of Radiance Caching will roll out to developers in 2026 rather than being fully user‑testable on day one. Treat Radiance Caching as a near‑term capability, but not yet ubiquitous in shipping titles.

Platform, driver and hardware reality​

RDNA4 / RX 9000 focus​

The performance and visual advantages of Redstone are not evenly distributed across AMD’s portfolio. The ML models and fast on‑chip inferencing that Redstone uses require the new ML accelerators and precision modes on RDNA4 (Radeon RX 9000‑series) GPUs. AMD provides analytical fallbacks for certain features on older architectures, but reviewers and AMD’s own documentation show full Redstone functionality is RDNA4‑centric. Expect the strongest benefits only on RX 9000 series cards.

Windows 11 and DirectX 12 as the supported consumer path​

At launch, the driver package exposing Redstone — Adrenalin 25.12.1 — is distributed and validated for Windows 11 with DirectX 12. AMD’s public notes emphasize Windows 11 and modern system stacks as the supported deployment environment for this driver build; while some community experiments may coax parts of the stack to run on Windows 10, official support and the best experience are tied to Windows 11 and a DirectX 12 runtime. Those platform constraints matter in mixed‑fleet environments and for players who continue to run older OS versions.

Driver and rollout considerations​

Adrenalin 25.12.1 is WHQL certified and intended to ship with day‑zero support for selected titles, but early community reporting and AMD’s own guidance caution that driver maturity can initially be uneven. Major procedural recommendations include:
  • Create a system restore point and back up GPU profiles before upgrading.
  • Perform a clean driver install (DDU) if you are testing bleeding‑edge features.
  • Update Windows 11 to the latest cumulative build before installing the driver.
  • Use objective capture tools (PresentMon, CapFrameX) and recorded clips to evaluate image quality and latency tradeoffs.
These are pragmatic steps to reduce regression risk as studios and drivers iterate on Redstone integrations.

Linux reality: no native FSR Redstone day‑one support (and why that matters)​

What’s shipping — and what isn’t​

AMD’s official rollout is explicitly Windows‑focused: Redstone, the FSR SDK 2.1 runtime and the Adrenalin toggles are distributed and validated in a Windows 11 + DX12 environment. There is no native Linux (Vulkan/OpenGL) packaging or RDNA4‑specific Mesa driver component that delivers the full Redstone ML path at launch; therefore, Linux desktop players will not have direct, out‑of‑the‑box access to the new ML features on day one. GamingOnLinux and multiple industry outlets noted this Windows‑first approach.

Proton / Wine and the compatibility layer question​

That leaves Proton (Valve’s Wine fork) and Wine as the practical routes for many Linux gamers. Proton has matured into a robust compatibility layer for many DirectX titles by translating Direct3D calls to Vulkan and packaging runtime fixes, so it’s the likely pathway for Redstone‑enabled Windows games to run on Linux systems. However, Proton’s ability to surface driver‑level toggles and to interoperate with AMD’s Windows‑only driver components is limited:
  • Some Redstone features are implemented in the driver and activated via Windows‑side toggles; those toggles may not be visible or functional under Proton unless the game itself calls into the SDK functions and those calls are correctly translated.
  • Anti‑cheat, DRM and other kernel‑level Windows integrations remain a potential blocker for multiplayer titles running under Proton unless developers explicitly support Proton or Valve provides runtime shims.
  • Even when the Redstone model calls are present in the game, the translation to Vulkan must preserve the ML model inputs and outputs; that’s non‑trivial and will likely require collaboration between AMD’s Linux driver teams, Valve and the Proton community.
In short: Proton can be a bridge, but it will take engineering work and time for Redstone’s driver‑level experiences to appear reliably on Linux systems. Community reports and technical writeups show that Proton has solved many compatibility problems, but driver‑deep ML features present a new class of complexity.

Early reception: performance, quality and limits​

What independent testing shows so far​

Early coverage and tests from respected outlets and reviewers show measurable framerate improvements and clear image‑quality wins in specific scenarios, particularly:
  • Ray‑traced scenes that were previously denoiser‑limited see significant perceived quality improvements when Ray Regeneration is active.
  • ML Frame Generation combined with upscaling can elevate framerates in CPU‑bound or ray‑trace‑bound scenes to higher refresh bracket targets, especially at 1440p and 4K.
  • However, the most dramatic vendor‑presented numbers are best‑case illustrations and do not reflect average gameplay across all titles.
Multiple independent outlets note that day‑one title support is still limited (roughly 30–40 titles with driver‑applied toggles at launch), and that full Radiance Caching integration was promised on a longer schedule. Those caveats are important: you will not see universal, across‑the‑board DLSS‑style availability immediately.

Image‑quality tradeoffs and artifacts​

Real‑time ML approximations necessarily make tradeoffs. Early reviewers report that:
  • ML frame generation is better at reducing ghosting and motion discontinuities than basic analytical interpolators but can still produce artifacts in very high‑frequency or complex motion situations.
  • Ray Regeneration handles reflections and specular noise far better than low‑sample brute force methods, but success depends on per‑title tuning and how the game exposes necessary inputs (normals, albedo, motion vectors).
  • Radiance Caching promises fewer temporal flicker problems for GI once mature, but it will need careful engine‑level integration to avoid ‘caching smearing’ or lagged illumination updates in highly dynamic scenes.
Expect iterative quality improvements over several driver and game patch cycles as studios and AMD tune per‑title models.

Developer and industry implications​

For game studios and middleware​

FSR SDK 2.1 provides a modular path to integrate ML upscalers, frame gen and ray assistance without building bespoke neural pipelines in‑house. That reduces engineering overhead for teams that want DLSS‑style results but prefer an alternate vendor ecosystem. However:
  • Game devs must still integrate the SDK and expose the necessary G‑buffer channels (motion vectors, depth, normals, material parameters) for the ML models to work well.
  • Per‑title model fine‑tuning will be required to avoid artifacts and to hit frame‑time goals on a range of hardware.
  • Studios that commit to Redstone can yield substantial performance savings in path‑traced lighting budgets, but that requires coordination with QA, driver teams and patch pipelines.

For hardware competition​

AMD’s move makes ML accelerators and low‑precision inferencing first‑class GPU features. The market reaction from competitors will likely accelerate similar ML investments and faster cross‑vendor tooling. That intensifies the value proposition of cards that ship with capable ML hardware and may reshape how GPU architectures allocate die area between raw shader throughput and ML primitives.

Risks, limitations and adoption friction​

  • Hardware exclusivity: The clearest adoption blocker is that full Redstone capability is tied to RDNA4 — users on RDNA3 or older will only see fallback analytical modes for some features. This creates a hard boundary that will slow uptake.
  • Driver and OS coupling: Redstone’s best experience is on Windows 11 and an Adrenalin driver that’s WHQL‑certified for this feature set. Enterprises and users on older OS versions face a compatibility gap.
  • Per‑title engineering: The top visual quality depends on per‑title integration and tuning. Titles that rely solely on a driver toggle may not reach the same fidelity as engines that integrate the SDK natively.
  • Anti‑cheat and multiplayer: Kernel‑level anti‑cheat and DRM can block or complicate Proton/Wine compatibility on Linux and can also complicate driver‑level toggles on Windows; studios and platform holders must coordinate.
  • Initial driver maturity: Major driver releases that introduce new distributed features often face teething issues (stability, INF mismatches, regressions). Conservative deployment and backups are wise for production rigs.
Where claims are vendor‑led (for example, “up to X×” speedups in very specific path‑trace workloads), treat them as illustrative best cases until independent labs reproduce the same numbers across a range of titles and conditions. Those vendor top‑lines are useful signposts, not guarantees.

Practical guidance for WindowsForum readers​

If you have RDNA4 hardware and want to try Redstone now​

  • Back up system and GPU profiles, create a Windows restore point.
  • Update to the latest Windows 11 build and install any chipset/firmware updates.
  • Optionally use DDU (Display Driver Uninstaller) to perform a clean driver uninstall, then install Adrenalin 25.12.1. This reduces the chance of residue conflicts with older driver stacks.
  • Test with a small, representative set of titles (a ray‑traced scene, a CPU‑bound scenario, and a high‑refresh competitive title).
  • Use PresentMon / CapFrameX to capture average FPS, 1% lows and frame‑time distributions before and after enabling Redstone features.
  • Record short gameplay clips and scrub frame‑by‑frame to inspect artifacting—ML frame gen and denoising artifacts are often easiest to spot in motion or in replays.

If you’re on older AMD GPUs or Linux​

  • Hold off on expecting Redstone miracles. RDNA3 and earlier will generally receive analytical fallback modes; you will not see RDNA4‑level ML gains.
  • On Linux, follow ProtonDB and community maintainers for the first reports of workable Redstone gameplay under Proton; be prepared for partial functionality at first. Valve, AMD and the Proton community will need to collaborate to make driver‑level features fully functional on Linux.

Final analysis — value, timing and where this sits in the market​

FSR Redstone represents a meaningful technical pivot for AMD: the company is moving from purely analytical upscaling toward a unified ML pipeline that touches frame generation, denoising and illumination caching. If AMD’s SDK finds wide adoption, the company will be competitive with other ML‑driven ecosystems and the result will be better framerates and faster GPU‑driven ray tracing for titles that integrate these tools. Early independent reviews confirm tangible gains in select workloads, and early in‑game implementations (notably in Call of Duty: Black Ops 7) show the concept works in practice. That said, the launch is bounded by several pragmatic limits: RDNA4 exclusivity, Windows 11 / DirectX 12 centricity, and per‑title adoption requirements. These constraints will slow universal uptake and complicate the experience for Linux users and owners of older Radeon hardware. Moreover, initial driver maturity and the inevitable per‑title tuning will make the first months of Redstone a mix of big wins in some games and uneven behavior in others. Reviewers and independent test labs will continue to refine the community’s understanding over the next driver cycles. In sum: FSR Redstone and the AMD FSR SDK 2.1 are strategically important — they modernize AMD’s approach to upscaling and ray‑assist by leaning into ML — and they deliver immediate benefits where the hardware and software ecosystem align. For adventurous RDNA4 owners who want to experiment, the gains can be substantial; for the broader installed base, the full promise of Redstone will arrive more gradually, shaped by developer integrations, driver updates and cross‑platform coordination.
Conclusion
AMD’s FSR Redstone is a technically bold release that brings ML‑driven frame generation, ray reconstruction and learned radiance caching into the mainstream SDK and driver pipeline via AMD FSR SDK 2.1 and Adrenalin 25.12.1. The suite is a meaningful step toward lowering the cost of ray tracing and boosting effective framerates, but it arrives with clear hardware and OS boundaries that will define who benefits immediately and who must wait. Expect a multi‑quarter adoption curve: fast wins in high‑profile, engine‑integrated titles and slower, steadier improvements as the ecosystem — studios, AMD, Microsoft/Valve and driver teams — synchronizes on the SDK and runtime behaviors.
Source: GamingOnLinux AMD FSR Redstone arrives with AMD FSR SDK 2.1
 

Back
Top