DLSS Frame Generation Latency: 2026 UE5 vs Unity Benchmark

A game can report 120 FPS and still feel like a 40 FPS game. That apparent contradiction comes from separating displayed frames from the frames that actually advance the game.

DLSS Frame Generation can insert intermediate images between traditionally rendered frames. It can make camera movement look smoother, but the native frame still determines how quickly input, gameplay code, animation and much of the rendering pipeline advance. For a meaningful Unreal Engine 5 versus Unity 6 comparison, measure native frame time first. Treat generated output as a second result, not the foundation of the benchmark.

Key takeaway: A 40 FPS base render takes 25 ms per frame, even when Frame Generation raises the displayed cadence to 80 FPS.

What the benchmark must measure

Modern frame budgets leave little room for hidden costs:

A scene that takes 25 ms to render natively is running at 40 FPS. Frame Generation may add an intermediate image, but it hasn’t turned that scene into an 80 FPS simulation. If the CPU spends 20 ms on gameplay, animation, physics or streaming, changing the display cadence won’t shorten that work.

The same distinction applies to frame pacing. A sequence alternating between 12 ms and 35 ms frames may produce a reasonable average while feeling uneven. Generated images can make camera motion appear less harsh, but shader compilation, asset streaming and CPU spikes still need to be fixed in the underlying workload.

A useful capture should include at least:

• Native FPS and frame time
• Displayed FPS with Frame Generation enabled
• CPU game-thread and render-thread time
• GPU frame time
• 1% and 0.1% lows
• VRAM and system memory
• Shader compilation and traversal stalls
• Input-to-photon latency
• Build, import and shader-cache time

Use a repeatable route rather than a convenient screenshot. A dense traversal path, a busy combat encounter and a first-run shader pass usually expose more than a polished showcase scene.

Nanite and GPU Resident Drawer solve different problems

Nanite and Unity 6’s GPU Resident Drawer are often presented as rival answers to the same rendering problem. They aren’t.

Nanite virtualizes geometry through hierarchical clusters, GPU-driven visibility processing and automated detail selection. Its production advantage is often as important as its runtime behavior: artists can work with much denser static geometry without maintaining extensive hand-authored LOD chains.

That advantage has limits. Materials, overdraw, foliage, skeletal meshes, texture residency, Virtual Shadow Maps and Lumen can still dominate a frame. Nanite reduces some geometry-management costs; it doesn’t make a complicated material or a memory-starved scene inexpensive.

Unity 6’s GPU Resident Drawer focuses primarily on instance management and CPU-side submission. It is most useful when a scene contains many compatible mesh instances and the CPU spends too much time preparing draw calls. It does not replace sensible asset organization or solve every renderer bottleneck.

Unity Technologies reported “up to” 4× CPU improvement in selected GPU Resident Drawer and Render Graph workloads, and more than 2× improvement in certain scenes with high instance counts or full-screen effects. Those figures come from Unity’s product materials, not an independent UE5-versus-Unity test. They’re useful reasons to investigate the feature, not numbers to paste into a production plan.

A fair comparison uses equivalent geometry, textures, camera paths, lighting targets and quality settings. Profile Unreal with Unreal Insights and Unity with the Profiler or Profile Analyzer. Record frame times with PresentMon or OCAT so both engines are judged using the same capture method.

Lumen and neural rendering need separate accounting

Lumen adds a substantial lighting workload, and its cost varies sharply with resolution, reflections, hardware ray tracing, foliage and dynamic-object count. Epic’s UE5.8 documentation, published in 2026, reports that Lumen Medium is approximately twice as fast as Lumen High in its tested quality comparison. That is a useful quality-scaling reference, not a guaranteed result for every project.

When comparing engines, keep lighting targets equivalent. A UE5 scene using Lumen High should not be compared with a Unity scene using baked lighting or a lower reflection standard. Record the visual target as well as the performance result; otherwise, the faster engine may simply be doing less work.

Neural rendering features also have distinct costs:

• DLSS Super Resolution reconstructs a higher-resolution image from a lower-resolution base render.
• Ray Reconstruction replaces or supplements denoising for supported ray-traced effects.
• Frame Generation creates intermediate frames using motion data and optical-flow analysis.
• Multi Frame Generation creates several additional frames on supported hardware.

Super Resolution can reduce GPU shading and pixel work. Frame Generation requires motion vectors, depth data and GPU headroom. If the base render already occupies nearly the entire GPU budget, the added processing may reduce the benefit or increase latency.

NVIDIA’s DLSS 4.5 materials, released in 2026, describe Multi Frame Generation producing up to five additional frames per traditionally rendered frame on suitable RTX 50-series hardware. That is a capability claim under supported conditions, not a universal game result. A shipping renderer still needs a path for older RTX cards, AMD hardware, consoles and systems without the required motion data.

NVIDIA’s 2025 RTX Neural Shaders materials also report up to 7× memory savings for RTX Neural Texture Compression and up to 5× faster processing for some Neural Materials workloads. Before adopting those techniques, test image quality, shader occupancy, inference overhead, asset conversion time and fallback behavior. A result that looks excellent on one NVIDIA card may create a poor cross-platform production path.

How to measure latency properly

Latency needs its own method; displayed FPS is not a substitute.

Run each test with NVIDIA Reflex disabled, enabled and, where applicable, enabled with Boost. Record whether V-Sync, G-Sync or an equivalent display mode is active. Use a high-speed camera or a hardware capture device such as NVIDIA LDAT, FCAT-style equipment or an equivalent photodiode-and-input setup.

State exactly what is being measured:

• System-level input-to-photon: physical mouse or controller actuation to a visible pixel change.
• Click-to-photon: a narrower test using a mouse switch or click signal as the starting event.
• Sample count: collect at least 100 samples per configuration and report the median and 95th percentile.

Test native rendering, Super Resolution and Frame Generation separately. Keep the camera route and input action identical. A result showing 80 displayed FPS but latency close to the 40 FPS native case is not a failure; it is evidence that smoothness and responsiveness are being reported separately.

A practical cost comparison

Engine economics become clearer when tied to an actual team. Consider a 12-person studio making a $3 million product: six programmers and technical designers, four artists, one producer and one QA lead. Assume a three-year development cycle and no negotiated enterprise discounts.

Unity Pro is listed at $2,310 per seat per year in Unity’s 2026 pricing information. Twelve seats cost:

Unity seat cost: 12 × $2,310 × 3 years = $83,160

That estimate excludes cloud build, diagnostics, support and middleware. Unity’s predictable seat pricing can still be attractive for a team with an established C# pipeline and a multi-platform release plan.

Under the commonly cited Unreal commercial terms, the 5% royalty applies to worldwide gross revenue above the first $1 million per product:

Unreal royalty: ($3,000,000 − $1,000,000) × 5% = $100,000

Unreal may offset part of that cost when Nanite, Lumen, high-end tooling and integrated profiling replace work the studio would otherwise fund internally.

A custom engine has no engine royalty or seat fee, but it needs staff. A conservative estimate for two rendering engineers, one tools engineer and one build engineer over three years is $1.8 million in salary and employment costs. Add approximately $250,000 for middleware, platform support, hardware, build infrastructure and outsourced certification work:

These figures aren’t interchangeable quotes. Unity and Unreal still require engineering staff, while a custom engine can make sense when the technology itself is the product or when many releases will amortize the investment. The comparison shows why a royalty or subscription should be evaluated against labor, iteration speed, platform work and maintenance—not in isolation.

A four- to six-week vertical slice usually reveals the answer. Build the densest environment, busiest combat sequence and worst shader or streaming path. Track which team members fix each issue and how long it takes. That evidence is more valuable than a feature checklist.

Choosing the engine

Choose Unreal Engine 5 when dense environments, high-end lighting and ready-made rendering infrastructure are central to the product.

Choose Unity 6 when platform breadth, predictable seat costs, C# expertise and CPU-heavy instance submission make its workflow a better fit.

Choose a custom engine only when the studio can fund long-term engine ownership or has a specialized requirement that general-purpose engines cannot meet economically.

The benchmark should end with a native frame-time target, not a generated-FPS headline. Neural features can improve presentation after the simulation and renderer are stable. They can’t replace the work of making the game responsive, well-paced and affordable to build.