Frame Generation Explained: DLSS, FSR & AFMF (2026)

Frame generation can make motion look smoother by inserting images between rendered game frames. The displayed FPS rises, but the game has not simulated that many additional moments. Judge the picture and your control response. Both matter.

Start with it off. A stable, responsive base is useful before adding generated images. Use the availability guide, counter example and original latency results to understand the choices without making a new capture. The result record gives you a place to save settings if you later compare them on your own PC.

DLSS, upscaling, and frame generation are different switches

DLSS is a feature family. Super Resolution reconstructs a higher-resolution image from lower-resolution rendering. Ray Reconstruction improves reconstruction of ray-traced detail. Frame Generation adds display frames. The separate 3D-Guided Neural Rendering feature changes lighting and material detail in the final image. A DLSS version badge does not tell you which of those switches your GPU and game support. NVIDIA’s feature explanation

The same separation matters with AMD. FSR 3.1 makes frame generation optional and permits third-party upscalers when the game supplies the required motion vectors and depth data. You can compare the upscaler and generation mode separately.

Change one setting at a time. To isolate generation, hold output resolution, upscaling quality and supported latency controls constant while you switch it off and on; if a combined preset changes those settings too, the result belongs to that whole combination.

How generated frames are made

Original DLSS 3 combines sequential frames, game motion vectors and optical-flow information to create intermediate images. Later DLSS models change that processing; the original architecture is not a description of every current mode. FSR also interpolates between source images.

Generation can increase displayed FPS in a CPU-limited game because the extra image processing runs on the GPU. It does not speed up the underlying simulation. Use the CPU and GPU benchmark lookup for hardware context, while keeping a game’s rendering rate separate from its generated output.

DLSS availability: current, beta and announced

Checked October 23, 2026. These records describe supported features, not guaranteed FPS gains. The game integration still matters.

• Frame Generation / 2X: available on RTX 40 and RTX 50 in compatible games. One generated frame accompanies each rendered frame. DLSS Frame Generation support
• Multi Frame Generation up to 4X: available on RTX 50 in compatible games, natively or through a supported NVIDIA app override. Up to three generated frames accompany one rendered frame. DLSS 4 announcement
• Fixed 5X/6X: available on RTX 50 in selected titles with sufficiently recent FG DLLs. At 6X, the intended composition is five generated plus one rendered frame. NVIDIA’s March override release requires Game Ready 595.97 WHQL or newer; it does not publish a universal game-build or DLL minimum for every title. Fixed-mode requirements
• Dynamic Multi Frame Generation: available on RTX 50 in compatible titles; it adjusts the multiplier toward a target frame rate or refresh rate. The current Streamline implementation requires D3D12. The synchronization conditions below also matter. Dynamic-mode description, pinned integration guide
• FG Performance Mode: beta for RTX 40 and RTX 50 in supported FG games. October’s announcement calls it Preset C; the current app release catalog calls it Model C, under the Frame Generation model selector. This changes the generation model and its performance/quality tradeoff. It does not enable 6X on RTX 40. October announcement, current app catalog
• 3D-Guided Neural Rendering: a separate DLSS 5 feature for supported local RTX 50 games, not another multiplier or upscaling mode. Availability is game-specific; it was released in NBA 2K27 in September, while the two examples below still have future dates. September release

Two games show why a single “DLSS supported” label is insufficient. NVIDIA’s game matrix, dated October 13, lists different MFG ceilings. Its separate announcement supplies the Neural Rendering dates.

Those entries establish the published support status. They do not identify your installed game build or FG DLL, and a future update announcement does not make its feature available today.

FSR and AFMF use different paths

Checked October 23, 2026. Identify the exact feature before following a driver guide.

Integrated FSR 3/3.1 is the cross-vendor path built into a game. FSR 3.1 can separate generation from its upscaler; the particular game’s integration determines the available combination. FSR 3 integration

Current ML FSR Frame Generation requires RX 9000-series or newer hardware, Windows 11 and a supported DX12 integration. AMD’s SDK 2.3 includes FG 4.0.1; its developer requirements include Shader Model 6.6 and Agility SDK 1.4.9+. Those SDK components belong to the game integration. Players use supported game and driver controls. FG 4.0.1 manual, SDK contents

The analytical fallback has a wider hardware scope. SDK 2.3 includes analytical FG 3.1.6 and swapchain 3.1.7, documented for RX 5000 or newer, or equivalent hardware from another vendor, with Shader Model 6.2. This current path uses DX12 and Windows 10/11; legacy FSR 3’s Vulkan support does not extend it to Vulkan. SDK requirements, current FG requirements, legacy FSR 3 integration

For a driver upgrade to ML FG, AMD specifies standard FSR FG 3.1.4+ integration, Windows 11/DX12, RX 9000 hardware and Adrenalin 25.12.1+. Native FG 4.0+ is another supported integration route. Check the specific Frame Generation game list; support for ML upscaling alone does not establish ML FG support.

AFMF 2.1 operates through the Radeon driver. AMD lists Adrenalin 25.3.1+, Windows 10/11 and DX11/12, Vulkan or OpenGL. VSync must be off in both the driver and game. AMD recommends FreeSync and supports Radeon Chill. AFMF requirements

Check the display mode. RX 6000 requires exclusive fullscreen; RX 7000 and newer support borderless fullscreen. For Ryzen, AMD lists qualifying Radeon 700M-or-newer graphics and excludes select Ryzen 7000 models with GCN or RDNA 2 graphics. Check the exact graphics model against the device requirements.

Feature support and driver-package support are separate checks: AMD’s 26.10.1 notes recommend OEM drivers for laptops and all-in-one PCs, and exclude handheld gaming devices from the generic package, directing those users to their device manufacturer. OEM driver guidance

Record whether you used the per-game control or HYPR-RX, which enables multiple features. An enabled toggle alone is not a measurement of active generation.

Read a frame counter without inventing a result

Hypothetical illustration, not a hardware capture: assume complete coverage of one known display-event interval lasting 1.000 second. Count display onsets from 0.000 seconds inclusive to 1.000 seconds exclusive on the same clock. Follow one process, swapchain and display output, with each displayed event counted once. The event origins are known for this example.

The displayed rate is 240 frames/s: (60 + 180) / 1.000. Its application-origin component is 60 displayed frames/s. That component is not automatically the total rendering rate, an FG-off baseline or the game’s simulation rate.

Now change one fact. Suppose the corresponding cohort still contains 180 generated records, but 10 did not display. With 60 displayed application-origin and 170 displayed generated-origin events in the same known one-second interval, the displayed total becomes 230 frames/s. Origin and display outcome are separate questions. The 10 not-displayed records have no display-onset timestamps to place inside that interval; do not manufacture them from CPU-start times.

If the only supported measurement is 240 displayed frames/s and origin labels are missing or ambiguous, keep 240 and write origin split unknown; dividing that total by a selected 4X mode does not recover the missing application FPS.

The denominator matters too. If the interval or coverage is unknown, retain the counter’s own label and limits instead of claiming a reconstructed matched rate.

The arithmetic also explains a common latency mistake:

• 1000 / 60 ≈ 16.667 ms
• 1000 / 240 ≈ 4.167 ms

These are rate-equivalent intervals. They measure neither input latency nor the distribution of actual time gaps between displayed frames. A higher average does not establish evenly spaced output.

What PresentMon can and cannot supply

Record its version and metric options. In the PresentMon v2.6.0 console documentation, --track_frame_type is optional, beta, and requires application/driver instrumentation. It is not a universal origin detector. --exclude_dropped removes not-displayed rows, so their missing count remains unknown. --no_track_display disables display tracking; v1 and v2 metric modes differ.

The tagged CSV writer can write Application for unset or repeated internal frame types as well as application-origin frames. That label alone cannot prove the split above. The separate column named Application is the process name.

In tracked v2 output, DisplayedTime is a displayed duration, with NA for a not-displayed frame. A blank, missing or rounded-to-zero value is not interchangeable with that NA. CPUStartTime is not display onset, and DisplayLatency is a frame-start-to-display metric. Preserve those meanings and any unknowns; this example is not an importer for arbitrary CSV exports. Tagged metric definitions, v2 writer

A measured example: higher FPS and more latency

Interpolation adds processing time. Reflex or Anti-Lag can reduce other pipeline delays, and upscaling can change the rendering workload, so a combined preset with lower latency than native rendering does not establish that frame generation itself reduced delay. NVIDIA’s combined-feature comparison, AMD’s latency guidance

My June 8–11, 2026 RTX 5080 dataset illustrates the tradeoff. These are the original chart 05 labels and values from the ASUS ROG Astral RTX 5080 OC, running Cyberpunk 2077’s in-game benchmark at 3840×2160 with RT Overdrive. DLSS-on runs use Quality mode and Reflex is on. The card uses the recorded manual User Mode 2 profile. Dataset and method, original card review

Within the DLSS Quality runs, adding generation raises the recorded output counter from 40 to 90 or 135 FPS, while PC Latency rises from 45 to 55 or 62 ms. Comparing native directly with MFG changes upscaling as well as generation, so it cannot isolate generation’s latency cost. Nor can the 40-FPS FG-off result be substituted for an unrecorded FG-on input rate.

Keep the original PC Latency name. The dataset describes the in-game latency overlay cross-checked with NVIDIA Reflex telemetry; do not relabel it input-to-photon latency. Chart 05 does not supply the exact game build, driver or FG DLL version. These June aggregates do not establish October mode behavior, individual frame origins or image quality.

Choose a useful base rate, then judge the picture

AMD recommends at least 60 FPS before interpolation and advises avoiding inputs below 30 FPS in both its FSR 3 guidance and current FSR Frame Generation guidance. The input may already include upscaling. This is a recommendation for those paths; it is not a universal DLSS/FSR/AFMF quality threshold, and the hypothetical 60 above is simply an arithmetic input.

Look at motion. If you choose to compare with an existing game, replay one scene and inspect moving edges, the HUD and newly revealed background. Record visible artifacts separately from how the controls feel. Leave image quality unobserved if you only have a numerical result; a larger counter cannot answer that question.

Sync settings depend on the generation path

NVIDIA’s March Dynamic-mode guidance prohibited VSync and frame limiters. Its September 3 update adds conditional support: the corresponding NVIDIA app update, Game Ready 616.64 WHQL or newer, and Streamline 2.14 or newer. The announcement does not supply a numeric minimum app version. If the app’s Dynamic-mode tooltip still warns of incompatibility, NVIDIA says a required component is missing.

There are further limits. The pinned Streamline guide, version 2.14.16, requires the runtime VSync-support flag and scopes FG VSync to D3D12; its implementation excludes Vulkan and GeForce NOW. It also warns that losing Independent Flip presentation, or combining high multipliers with a low-refresh display, can raise latency. Those conditions prevent a universal VSync/limiter recipe.

AMD’s integrated-FSR guidance considers VRR and VSync together. AFMF retains its separate VSync-off requirement.

AMD’s 26.10.1 notes, October 20, recommend in-game VSync for affected RX 9000 users experiencing crashes or hangs while switching apps or toggling overlays with integrated FSR FG enabled. For the separate Cyberpunk 2077 issue on some RX 9000 cards involving FSR Upscaling, Anti-Lag, in-game FG and video playback on a second display, AMD recommends disabling in-game FG. Apply the workaround only to its named combination. AMD known issues

There is also a separate overlay conflict: if a game crashes or times out when another overlay opens or closes while AMD’s Performance Metrics Overlay is active, the same notes recommend temporarily disabling the metrics overlay. That is a different condition from the integrated-FG crash above. 26.10.1 overlay issue

For the underlying display concepts, see the VSync and VRR guide and screen-tearing diagnostic. Follow your generation path’s requirements when using those general guides.

Keep a result you can compare

Copy this blank record or download the editable text file. Fill it from information you already have. You can use it to review a published result without running a game or buying equipment.

Keep FG-off FPS, FG-on input/render FPS and the displayed application component distinct. Use the tool’s exact counter labels. Record “unknown” when the source does not supply a value, and “not measured” when no measurement was made.

Frame generation record
Observed date: unknown
Game / build: unknown
Scene / duration: unknown
GPU / profile: unknown
OS / API: unknown
Driver / package: unknown
Feature / version: unknown
Model / multiplier: unknown
Channel / override: unknown
Output / render res: unknown
Upscaler / quality: unknown
Reflex / Anti-Lag: unknown
VSync game / driver: unknown
VRR / refresh Hz: unknown
Display mode: unknown
Tool / version: unknown
Options / metric mode:
  unknown
Interval / scope:
  unknown
Exact counter labels:
  unknown
FG-off FPS: not measured
FG-on input / render FPS:
  not measured
Displayed FPS: not measured
Displayed application FPS:
  not measured
Generated / unknown origin:
  not measured
Not displayed / omitted:
  unknown
Latency value / unit:
  not measured
Latency label / method:
  unknown
Image / response notes:
  not observed
Evidence / source: unknown

When I would leave frame generation off

Start with it off when responsive controls matter most. Lower the rendering workload if the base already feels slow, then consider generation for smoother motion. Keep it only when the picture and response suit the game you play.

For a hardware decision, use the 4K GPU guide and GPU comparison alongside this distinction. A generated-output FPS figure alone is not enough to choose a card.