DLSS 5 120 FPS Performance: UE5 Frame-Time Cost Benchmark

A 120 FPS target allows just 8.33 milliseconds per frame. One current workload estimate puts the combined DLSS 5 path at 7.9 ms at 4K on an RTX 5090. That leaves roughly 0.43 ms for everything else: Unreal Engine 5 rendering, game logic, post-processing, UI, synchronization, and presentation.

So, can DLSS 5 run at 120 FPS? Yes—but not if the rest of the frame is already expensive. At 4K, the neural workload can consume almost the entire budget before Nanite, Lumen, shadows, or simulation get meaningful time.

Key takeaway: A displayed 120 FPS number is not the same as a 120 FPS base render. For a responsive game, measure the input-driven frame rate, GPU frame time, generated-frame cost, and end-to-end latency separately.

The 120 FPS budget

The basic calculation is straightforward:

Frame time = 1,000 ms ÷ target FPS

That time covers the whole frame, not just the main rendering pass. The CPU still has to handle input, animation, visibility, physics, AI, and gameplay logic. The GPU must process geometry, materials, lighting, shadows, reflections, transparency, post-processing, UI, and any neural features.

A practical 120 FPS target often leaves only about 4–5 ms for the main GPU renderer after CPU-related work, presentation overhead, and smaller GPU passes are accounted for. That margin disappears quickly in a scene using Lumen, Virtual Shadow Maps, hardware ray tracing, and high-resolution materials.

This is also why a game running at 120 FPS before DLSS is enabled tells you very little. If its conventional frame takes 8.33 ms and DLSS adds 7.9 ms, the combined work is approximately 16.23 ms:

1,000 ÷ 16.23 ms ≈ 61.6 FPS

That is effectively a 60 FPS render with an expensive additional stage—not a 120 FPS pipeline.

What the reported 7.9 ms includes

“DLSS 5” should not be treated as one indivisible operation. A modern neural display path may contain several distinct jobs:

• Super resolution or reconstruction: produces a higher-resolution image from a lower-resolution input.
• Frame generation: creates an intermediate frame from previous images, motion data, and optical-flow information.
• Transformer or neural-rendering stages: may improve image quality or generate additional visual detail, depending on the mode and implementation.
• Supporting work: motion-vector preparation, history management, resource transitions, and compositing.

The reported 7.9 ms at 4K on an RTX 5090 appears to describe the combined DLSS 5 workload in a particular test, rather than a universal cost for one isolated neural kernel. The published result should therefore be treated as a workload-specific GPU estimate. It does not establish that every game, quality mode, or DLSS feature consumes 7.9 ms.

It also should not be confused with end-to-end latency. A GPU pass-time measurement normally excludes parts of the input-to-display path, including CPU scheduling, queue depth, scan-out, and display response. Readers comparing results should check whether the capture measured GPU timestamps, frame-present intervals, or full latency with a tool such as Reflex Latency Analyzer.

At 1440p, the same report estimated about 3.6 ms on an RTX 5090. That leaves approximately 4.73 ms inside a 120 FPS budget, which is still tight but more workable for a restrained raster pipeline.

These figures come from a reported NBA 2K27 comparison and should not be presented as a standardized benchmark. Any reproducible version of the test would need the game build, driver, DLSS mode, internal render resolution, frame-generation setting, V-Sync state, capture tool, and whether the numbers represent GPU timestamps or displayed frame intervals. Without that information, use the table for planning rather than purchasing decisions.

Why UE5 scenes run out of time

Nanite reduces the cost and management burden of extremely dense geometry, but it does not make geometry free. Epic’s Lumen in the Land of Nanite demonstration reported roughly 2.5 ms for Nanite culling and rasterization, plus about 2.0 ms for material evaluation in that specific scene and configuration.

That is approximately 4.5 ms before Lumen, Virtual Shadow Maps, translucency, post-processing, UI, or neural rendering. It is not a fixed Nanite tax. A simpler scene can be far cheaper; a material-heavy scene can be more expensive.

Lumen often becomes the next constraint. At 1440p, a Lumen-heavy scene may fit within a carefully managed 120 FPS target if reflections, hardware ray tracing, and quality settings are controlled. Move the same scene to 4K and the image-processing, reflection, shadow, and bandwidth costs rise. The scene may still look similar in a screenshot, but a RenderDoc capture can reveal larger reflection and lighting targets, more expensive denoising, additional copies, and increased transient-memory pressure.

Virtual Shadow Maps behave similarly. Their cost depends on page invalidation, light movement, caster complexity, and how much of the world changes every frame. A static interior and a sunlit outdoor scene with foliage produce very different captures even when both use the same nominal shadow resolution.

Unity 6 takes a different route

Unity 6 gives teams more direct control over pass scheduling and resource lifetime through the Scriptable Render Pipeline, Render Graph, GPU Resident Drawer, GPU occlusion culling, and Forward+. Unity describes these systems in its Unity 6 release materials.

That control can help when CPU submission, redundant passes, or memory traffic is the primary bottleneck. Render Graph can remove dead work and reuse resources. GPU Resident Drawer can reduce repeated object submission. But none of these systems guarantees a faster neural path. If the GPU is already saturated by lighting or post-processing, better scheduling only creates limited savings.

The engine choice should follow the bottleneck, not a feature checklist. A team struggling with CPU submission may benefit more from Unity’s explicit control than from changing GPUs. A team building a cinematic world around Nanite and Lumen may accept UE5’s heavier baseline because those systems shorten content production.

Profile the frames players actually see

Average FPS is only one number. A useful test separates:

• Base-rendered FPS: the cadence of input-driven frames.
• Generated display FPS: the cadence after frame generation inserts images.
• GPU and CPU frame time: the actual bottleneck.
• Neural-pass time: preferably from GPU timestamps.
• 1% lows and frame pacing: whether the experience is stable.
• End-to-end latency: input to displayed response.
• VRAM allocation and streaming behavior: including evictions and stalls.

Use Unreal Insights with RenderDoc or Nsight Graphics for UE5. In Unity, combine the GPU profiler with Render Graph and platform-specific GPU captures. Capture the heaviest production scene, not an empty benchmark corridor.

A RenderDoc capture is especially useful when a frame-time number looks mysterious. It can show whether the GPU is spending time in Lumen reflections, shadow-page updates, material permutations, texture barriers, or a neural dispatch. At 4K, it may also expose a less obvious problem: large render targets and history buffers consuming bandwidth even when shader occupancy looks reasonable.

Pass overlap matters, too. The simple 8.3 ms plus 7.9 ms example assumes the costs stack cleanly. In a real frame, asynchronous compute, graphics scheduling, barriers, and resource dependencies can allow partial overlap—or introduce bubbles that make the total worse. Frame pacing can also change when generated frames are inserted, even if the average GPU time looks acceptable.

For a 120 FPS target, keep the base GPU frame near 5 ms if the neural path costs several milliseconds. If Nanite and materials already consume 4.5 ms in the target scene, Lumen, shadows, CPU work, and presentation have very little room left. A 4K generated-120-FPS mode may be a reasonable cinematic option, but it should not be marketed as equivalent to a native 120 FPS response.

The practical question is not “What FPS does DLSS 5 show?” It is: how many milliseconds remain after the base renderer, neural stages, game systems, memory traffic, and latency target are all counted?

A 60 FPS base render displayed at 120 FPS can look smoother, particularly in a single-player game. It still does not sample input, run simulation, or produce new fully rendered frames at the same cadence as a genuine 120 FPS pipeline. For competitive games, protect the base-rendered frame rate first. For cinematic games, generated frames may be a worthwhile trade—but only when frame pacing and latency remain acceptable.