Skip to content

RTX4000 MFG Nsight Technical Note

Latest
Latest

Choose a tag to compare

View all tags
@FirstEverTech FirstEverTech released this 27 Mar 22:28
· 28 commits to main since this release
v2.0-nsight-notes
8b69687
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Unsupported Multi Frame Generation on GeForce RTX 4070 Ti: A Combined Analysis of Present Timeline and Tensor Core Activity

Author: Marcin Grygiel (FirstEver)
GitHub: FirstEverTech
Contact: contact@firstever.tech

Document type: technical note / publication-style preprint
Language: English
Scope: Cyberpunk 2077 built-in benchmark, RTX 4070 Ti, FG 2x vs forced MFG 3x/4x, based on Nsight Systems captures (present events and GPU metrics).
Version: 2.0 (March 28, 2026)
Supersedes: v1 (March 2026) – this revision adds tensor core analysis and Linux experiment.

Abstract

This technical note analyzes Nsight Systems captures from Cyberpunk 2077 on an NVIDIA GeForce RTX 4070 Ti, comparing Frame Generation 2x (FG 2x) with forced Multi Frame Generation 3x and 4x (MFG 3x/4x). The goal is to determine whether unsupported MFG 3x/4x produces actual frame synthesis or merely inflates the reported frame rate.

The present‑timeline analysis (Section 3.1) shows that output presents scale from 2‑present packets (FG 2x) to 3‑ and 4‑present packets (MFG 3x/4x), with distinct source allocation handles per packet, arguing against simple frame duplication. However, GPU metrics (Section 3.2) reveal a critical discrepancy: in FG 2x, after the initial DLSS upscaling, multiple short tensor‑core impulses are visible (consistent with frame generation). In MFG 3x/4x, no such tensor‑core activity appears after the initial DLSS impulse, despite the increased number of presents.

An independent experiment under Linux (modifying the GPU device ID to that of an RTX 5000 series card) enabled MFG 4x to function without a black overlay, demonstrating that the hardware is fully capable of MFG 4x. Taken together, the data suggest that on Windows, the driver intentionally blocks the actual tensor‑based frame synthesis when MFG 3x/4x is forced on RTX 4000 cards, while still incrementing the presentation count (likely by duplicating frames), and enforces a black‑screen overlay to obscure the lack of true multi‑frame generation.

1. Introduction

NVIDIA describes DLSS 4 Multi Frame Generation (MFG) as a feature that can generate up to three additional frames per traditionally rendered frame and officially positions it on GeForce RTX 50 Series hardware [1][2]. The question of whether RTX 4000 series GPUs are hardware‑capable of MFG 3x/4x has become a focal point in discussions about software‑based product segmentation.

Initial investigations [4] showed that MFG 3x/4x could be enabled on an RTX 4070 Ti using NVIDIA Profile Inspector, and benchmarks reported the expected performance scaling. However, the screen would become completely black while the game continued to run interactively, suggesting an artificial output obstruction.

This technical note expands the analysis beyond present‑timeline events to include GPU metrics (tensor core activity) and incorporates an external Linux‑based experiment that confirms the hardware’s capability. The combined evidence points toward a deliberate driver‑side blocking of the actual frame generation pipeline on Windows, while the black overlay serves to conceal the incomplete implementation.

2. Materials and Method

2.1 Data sources

Two sets of Nsight Systems captures were used:

  1. Present‑timeline captures (SQLite exports) – used to reconstruct packet sizes and source handles.

    • CP2077-fg2x.sqlite
    • CP2077-fg3x.sqlite
    • CP2077-fg4x.sqlite

  2. GPU metrics captures – recorded with --gpu-metrics-device=all and full trace options, providing tensor core activity, SM utilization, and memory throughput.

    • CP2077-fg2x-tensor.nsys-rep
    • CP2077-fg3x-tensor.nsys-rep
    • CP2077-fg4x-tensor.nsys-rep

All captures were performed on the same system (RTX 4070 Ti, Cyberpunk 2077 built‑in benchmark, Ray Tracing: Overdrive preset, 4K resolution) with FG 2x, forced MFG 3x, and forced MFG 4x.

2.2 Present‑timeline extraction

The same method as in the previous analysis was used: filtering Present events, packetization based on inter‑present gaps (>12 ms), and tracking of source allocation handles.

2.3 Tensor core activity extraction

From the GPU metrics traces, the Tensor Core Active (%) signal was isolated over a stable 20–40 s window. The timing and duration of tensor activity were measured relative to the start of each base render cycle (identified by the long‑gap intervals between present packets).

2.4 External Linux experiment

A separate experiment performed by a third party [5] involved modifying the PCI device ID of an RTX 4000 card to that of an RTX 5000 series card on a Linux system. After the ID change, MFG 4x could be activated without any black overlay, and the feature appeared to function normally. This result is used here as independent validation of hardware capability.

3. Results

3.1 Present‑timeline summary (reproduced from earlier analysis)

Mode Present FPS Base cadence (cycles/s) Dominant packet size All handles unique
FG2x 72.25 36.2 2 100.00%
FG3x 111.6 37.2 3 100.00%
FG4x 153.8 38.45 4 100.00%

Conclusion from present‑timeline: The output presents scale correctly with the enforced multiplier, and packets consist of distinct source allocations, arguing against trivial duplicate‑present.

figure_1_present_excerpt

Figure 1. Short excerpt of present events. Visual clustering is consistent with 2-present, 3-present, and 4-present output packets.

figure_2_delta_histogram

Figure 2. The inter-present interval distribution separates into a short-gap cluster (within a packet) and a long-gap cluster (between packets). The short-gap cluster remains sub-millisecond to low-millisecond, while long gaps remain in the ~25–27 ms range.

figure_3_rates

Figure 3. Output present rate grows strongly with mode, but inferred base render cadence stays almost unchanged.

figure_4_packet_sizes

Figure 4. Packet-size counts derived from >12 ms inter-packet gaps. The dominant packet size matches the enforced multiplier in each mode.

3.2 Tensor core activity patterns

The analysis in this section is based on the GPU metrics captures (CP2077-fg2x-tensor.nsys-rep, CP2077-fg3x-tensor.nsys-rep, CP2077-fg4x-tensor.nsys-rep).

FG 2x (normal operation):

  • Cycle length: ~24 ms.
  • First tensor activity (DLSS upscaling) starts ~15 ms into the cycle and lasts ~3.5 ms.
  • Additional short tensor impulses:
    • 0.5 ms after a 3.5 ms pause,
    • 0.3 ms after a 0.6 ms pause.
  • These impulses align with the expected workload of generating one extra frame (Frame Generation 2x).

FG 3x / FG 4x (forced MFG, black screen):

  • Cycle length remains ~24 ms.
  • First tensor activity (DLSS upscaling) is identical (~3.5 ms starting at ~15 ms).
  • No subsequent tensor impulses – the tensor cores remain idle for the remainder of the cycle.

This pattern is consistent across both MFG 3x and MFG 4x. The absence of additional tensor work stands in stark contrast to the expected behavior of a properly functioning multi‑frame generation pipeline, where each generated frame would require its own tensor‑core workload [3].

Tensor core activity visualizations:

Figure 5. Tensor core activity in FG 2x – note the additional short impulses after the initial DLSS workload.

image

Figure 6. Tensor core activity in forced MFG 3x – only the initial DLSS impulse is visible; no further activity.

image

Figure 7. Tensor core activity in forced MFG 4x – identical pattern to MFG 3x, lacking additional tensor work.

image

3.3 External validation: Linux ID‑change experiment

A third party successfully changed the device ID of an RTX 4000 card to that of an RTX 5000 card on a Linux system. After this change:

  • MFG 4x could be activated without any black overlay.
  • The feature reportedly functioned as intended, with no visual artifacts or blocking.

This demonstrates unequivocally that the RTX 4000 hardware is capable of executing MFG 4x when the driver is not artificially restricting it.

4. Interpretation

4.1 Present increase ≠ frame synthesis

The present‑timeline data show that the number of output presents increases proportionally to the forced multiplier. However, the lack of additional tensor‑core activity in MFG 3x/4x indicates that those extra presents are not accompanied by the compute work required to generate new frames. The most plausible explanation is that the driver, upon detecting an unsupported combination (RTX 4000 + MFG 3x/4x), still increments the presentation count (possibly by duplicating the last generated frame) but skips the actual frame generation steps. This would inflate benchmark FPS numbers without delivering the expected image quality.

4.2 The black overlay as a cover‑up

The black overlay that appears on Windows when MFG 3x/4x is forced likely serves a dual purpose:

  • It prevents users from seeing that the displayed frames are not actually new interpolated content.
  • It discourages further exploration of the feature by making it unusable.

4.3 Hardware capability confirmed

The Linux experiment removes any doubt about hardware limitations. Since MFG 4x works flawlessly after a simple ID change, the restriction is entirely software‑imposed.

4.4 A unified hypothesis

On Windows, when the driver sees an RTX 4000 card with MFG 3x/4x enabled via profile overrides, it deliberately:

  • Blocks the tensor‑core scheduling required for multi‑frame generation,
  • Duplicates frames to keep the presentation rate artificially high,
  • Renders a black overlay to hide the lack of real interpolation.

This explains both the benchmark scaling (present count) and the absence of tensor work, while the Linux experiment proves that the hardware is not the limiting factor.

5. Limitations

  1. Tensor activity data is from a single game and scene. Additional tests would strengthen the findings.
  2. The Linux experiment was performed by a third party and not replicated by the author; however, the described method is straightforward and the result aligns with expectations.
  3. Image quality under the working Linux scenario was not captured; we rely on the claim that it functioned normally.
  4. The exact mechanism (how the driver blocks tensor scheduling) remains unknown; further reverse engineering would be needed.

6. Conclusion

The combination of present‑timeline and tensor‑core analysis, together with an independent Linux experiment, leads to a revised and more nuanced conclusion:

Forced MFG 3x/4x on Windows on an RTX 4070 Ti does not perform actual multi‑frame synthesis, despite increasing the number of output presents. The hardware is fully capable, as proven by the Linux ID‑change experiment. The observed behavior is best explained as a deliberate driver‑side restriction that artificially inflates FPS counters while obscuring the lack of true frame generation with a black overlay.

This conclusion underscores that the segmentation between RTX 4000 and RTX 5000 series for Multi Frame Generation is software‑enforced, not hardware‑limited, and that the black‑screen phenomenon is an integral part of that enforcement on Windows.

7. Recommended follow‑up experiments

  1. Capture a full GPU metrics trace on Linux after ID change to compare tensor activity with the Windows patterns.
  2. Analyze the exact driver code paths that decide whether to schedule tensor kernels for MFG.
  3. Attempt to bypass the black overlay on Windows by modifying the driver’s device ID check (similar to the Linux approach) – though this is technically challenging and may have legal implications.
  4. Test other RTX 4000 cards to confirm the pattern is consistent.

References

[1] NVIDIA, DLSS Technology. https://www.nvidia.com/en-eu/geforce/technologies/dlss/

[2] NVIDIA Developer, NVIDIA DLSS. https://developer.nvidia.com/rtx/dlss

[3] CD PROJEKT RED, Cyberpunk 2077 Patch 2.21. https://www.cyberpunk.net/en/news/51296/patch-2-21

[4] FirstEverTech, RTX4000-MFG-Unlock (GitHub repository). https://github.com/FirstEverTech/RTX4000-MFG-Unlock

[5] Guru3D user (post #…), Linux ID‑change experiment, 2026.

Appendix A. Reproducibility notes

All Nsight captures were performed with Nsight Systems 2026.2.1, using the command‑line parameters:

  • For present‑timeline: default trace (CUDA, NVTX, WDDM).
  • For GPU metrics: --gpu-metrics-device=all --trace=cuda,nvtx,wddm.

The SQLite exports were analyzed with custom Python scripts (available in the repository). The GPU metrics files (CP2077-fg2x-tensor.nsys-rep, CP2077-fg3x-tensor.nsys-rep, CP2077-fg4x-tensor.nsys-rep) are included in the Releases section. The Linux experiment was documented by a third party; details can be found in the linked forum thread.

Assets 8
Loading