Benchmarking Driver vs. Engine Frame Generation

This article explores the critical differences between GPU driver-level frame generation, such as AMD Fluid Motion Frames (AFMF), and engine-level solutions like Nvidia DLSS 3 and AMD FSR 3 when benchmarking computer hardware. It covers how these technologies access game data differently, the unique challenges they pose for frame rate capture tools, how dynamic disabling impacts test consistency, and why traditional frames-per-second (FPS) metrics must be separated when evaluating hardware performance using these two distinct methods.

Pipeline Integration and Data Access

To understand how to benchmark these technologies, you must first understand where they sit in the rendering pipeline.

Engine-level frame generation is integrated directly into the game by the developers. Because it operates inside the game engine, it has access to crucial spatial data, including motion vectors (which tell the GPU exactly where objects are moving from frame to frame), depth buffers, and separated UI elements.

Driver-level frame generation operates entirely outside the game engine. The GPU driver intercepts the final rendered frames just before they are sent to the display. Because it has no access to the game’s internal motion vectors or depth data, it relies purely on optical flow analysis—comparing two completed 2D images to guess how pixels moved, and then interpolating a new frame between them.

Telemetry and Benchmarking Software Compatibility

The placement of these technologies in the rendering pipeline drastically changes how hardware reviewers capture performance data.

Standard benchmarking tools like CapFrameX, MSI Afterburner (RTSS), and Intel PresentMon hook into the graphics API (DirectX or Vulkan) to count frames as the game engine presents them. Because engine-level frame generation creates frames inside this pipeline, these third-party tools can accurately detect, measure, and log the generated frames alongside native frames.

Driver-level frame generation happens after the game engine presents the frame to the operating system. Consequently, traditional benchmarking software cannot see the interpolated frames. If a game runs at 60 FPS natively and driver-level generation doubles it to 120 FPS, MSI Afterburner will still report 60 FPS. To benchmark driver-level solutions, testers are forced to use the GPU manufacturer's proprietary overlay and logging tools, making independent verification and cross-vendor comparisons much more difficult.

Test Consistency and Dynamic Disabling

A core rule of hardware benchmarking is repeatability. Engine-level frame generation provides consistent behavior: once enabled, it stays enabled, generating a frame for every native frame regardless of what is happening on screen.

Driver-level solutions like AFMF often use a dynamic toggle to preserve image quality. Because optical flow analysis struggles with rapid changes on screen, driver-level frame generation will temporarily disable itself during fast camera pans or sudden movements to prevent severe visual artifacting.

In a benchmark scenario, this creates massive variance. If a tester moves the mouse slightly faster in one run than in another, the driver may disable frame generation more frequently, resulting in a lower average FPS. This makes apples-to-apples hardware comparisons nearly impossible in fast-paced games.

Frame Pacing and Latency

Frame generation increases the smoothness of visuals on screen, but it does not improve the responsiveness of the game. In fact, both methods add input latency because the GPU must hold onto a newly rendered frame to compare it with the previous one before generating the middle frame.

Engine-level solutions combat this by integrating directly with engine-level latency reduction technologies, such as Nvidia Reflex or AMD Anti-Lag 2. These tools synchronize the CPU and GPU workloads precisely, keeping latency manageable and predictable during benchmarks.

Driver-level frame generation cannot control the game engine's CPU queue directly. It must rely on driver-level latency reducers, which are less effective. Furthermore, because the driver is guessing frame insertion timing outside the game loop, frame pacing (the consistency of time between frames) is often much worse in driver-level implementations. Standard frame time graphs will not reflect the micro-stutter a user might actually see on their monitor when using driver-level interpolation.

Visual Fidelity vs. Performance Metrics

Historically, 120 FPS on one graphics card looked identical to 120 FPS on another, assuming the same game settings. Frame generation breaks this parity, and the divide between driver-level and engine-level makes it worse.

Because engine-level generation isolates the game's Heads-Up Display (HUD), crosshair, and menus, these static elements remain sharp while the 3D world is interpolated behind them. Driver-level generation cannot tell the difference between the 3D game world and a 2D health bar. It attempts to interpolate the entire screen, which results in visible distortion, ghosting, and shimmering around UI elements and text.

When benchmarking hardware, a reviewer cannot equate 120 FPS achieved via driver-level Smooth Motion with 120 FPS achieved via engine-level FSR 3 or DLSS 3. The engine-level result represents a significantly higher quality visual experience and more consistent frame pacing, even though the final FPS number on a benchmark chart appears identical.