RTX 5090: memory locked-clock request reduces RT performance and leaves ~142 W unused

[Loong0x00]

RTX 5090: memory locked-clock request reduces RT performance and leaves ~142 W unused

NVIDIA Open GPU Kernel Modules Version

610.43.03 (nvidia-open-dkms 610.43.03-3)

Proprietary-driver comparison

Not applicable: this is an RTX 50-series / Blackwell GPU. NVIDIA's R610 documentation states that Blackwell and later GPUs are supported only by the open kernel modules; the proprietary kernel module does not support this GPU.

Operating System and Version

Arch Linux

Kernel Release

7.1.4-arch1-1 (stable release)

Hardware: GPU

• NVIDIA GeForce RTX 5090 (GB202)
• PCI device ID: 10de:2b85
• PCI subsystem ID: 1043:89e3
• VBIOS: 98.02.2E.40.E0
• GSP-RM: enabled

Describe the behavior

On this RTX 5090, adding a paired NVIDIA memory locked-clock request while retaining the same memory offset and byte-identical GPU V/F curve causes a large, repeatable regression in a path-traced workload.

Compared with the unlocked state, setting the memory locked-clock range to 15000/15000:

• reduces average FPS by 16.43%;
• reduces average GPU clock by 118.1 MHz;
• reduces average one-second board power by 142.1 W (556.7 W to 414.6 W);
• leaves a large part of the unchanged 600 W board-power limit unused.

The memory clock under load is approximately 15001 MHz in both states. No Xid or thermal, hardware, power-brake, or software-thermal slowdown was reported.

The locked-clock request is submitted through NVIDIA's exported nvmlDeviceSetMemoryLockedClocks() API. LACT was used as the frontend, but the two controlled configurations differ only by the paired min_memory_clock and max_memory_clock fields. The +2000 MHz memory offset and all 127 GPU V/F points remain identical.

Reproduction

Hardware and workload:

• Cyberpunk 2077 2.31 built-in benchmark
• 6144 x 3456
• Path Tracing enabled
• no Frame Generation or Multi Frame Generation
• 600 W power limit

1. Apply a custom GPU V/F curve and a +2000 MHz memory offset without calling nvmlDeviceSetMemoryLockedClocks().
2. Run the built-in benchmark and record FPS, GPU clock, voltage, memory clock and board power.
3. Keep the same V/F curve, memory offset, power limit, fan settings and game settings.
4. Call nvmlDeviceSetMemoryLockedClocks(device, 15000, 15000).
5. Run the same benchmark again and record the same telemetry.
6. Reset the lock with nvmlDeviceResetMemoryLockedClocks(); performance and power use return to the unlocked behavior.

Results

State	Average FPS	Minimum FPS	Maximum FPS	GPU clock min/avg/max	GPU voltage min/avg/max	1 s board power min/avg/max
Custom V/F, +2000, no memory lock	11.8993	10.3161	13.9809	2827 / 2888.1 / 2932 MHz	945 / 970.6 / 990 mV	505.8 / 556.7 / 590.8 W
Same settings, memory locked at 15000/15000	9.9443	8.9323	11.3875	2715 / 2770.0 / 2827 MHz	905 / 916.8 / 935 mV	396.7 / 414.6 / 438.3 W

Independent 50 ms telemetry reported 97.6% average GPU utilization in the unlocked run and 99.2% in the locked run. Average instantaneous board power was 559.7 W unlocked and 415.0 W locked.

Read-only NV2080_CTRL_CMD_PMGR_PWR_POLICY_GET_STATUS sampling shows that the active WORKLOAD_COMBINED_2X policy enters a different state with the lock:

Field	Unlocked	Locked
Policy CurrLimit	400.87 W	456.07 W
Policy CurrValue	354.47 W	264.37 W
DG0 candidate	2944.12 MHz	2787.91 MHz
Branch-1 normalized workload	250.83	374.18
Branch-1 estimated value	188.25 W	276.76 W

This looks as though the strict memory lock changes the global performance-arbiter model and lowers the GPU-clock candidate even though actual board power falls substantially.

Expected behavior

Locking memory to the same frequency already reached under load should not reduce path-traced performance by 16.4% and leave approximately 142 W of the configured board-power limit unused.

Could NVIDIA confirm whether this interaction is expected on Blackwell, and whether the power/performance arbiter can be corrected so a memory locked-clock request does not unnecessarily reduce the graphics-clock budget?

The complete benchmark summaries, per-sample telemetry and read-only policy-status captures are available if useful. The LACT-side documentation report with the same controlled measurements is ilya-zlobintsev/LACT#1128.