Fermi (GF106) eDP 120Hz Display & Dynamic Reclocking on Nouveau

twilight0 · 2026-08-29 06:52:49

Hi everyone,

I've been working on getting full performance and modern kernel (6.18+ LTS) support on a Dell XPS L702X equipped with an NVIDIA GeForce GT 555M (Fermi GF106M, 3072MB DDR3, internal 1920x1080 @ 120Hz eDP panel).

I wanted to share my findings, ask for community insights, and open a discussion on high-refresh-rate eDP panels and display engine clocking under the open-source Nouveau driver.

1. Background & Current Achievements

Since the legacy proprietary driver (nvidia-390xx) is increasingly difficult to maintain on modern kernels and Xorg/XLibre versions, I’ve been maintaining an out-of-tree DKMS package (nouveau-fermi-reclock-dkms) with:

Core & Shader Reclocking: Successfully reclocking the GPC/ROP domains to full performance state 0f (590 MHz core / 1180 MHz shader) dynamically via a load-aware daemon (nouveau-dynclockd), taking unthrottled glxgears from ~320 FPS to ~2,700 FPS.
Fixed PMU/PRIVRING Hangs: Resolved the legacy Tesla PMU lock (0x10a580) bus faults that previously caused infinite hang loops during pstate transitions on Fermi.
Dedicated ACPI Backlight & Hotkey Driver: Handled native EC brightness queries and hardware PWM.

2. The 120Hz eDP Puzzle

While the proprietary 390.157 driver delivers a native 120 FPS VSync presentation rate, Nouveau presents an interesting case with high-refresh eDP panels:

DRM & XRandR Report 120Hz:

xrandr: 1920x1080 (0x45) 396.360MHz +HSync -VSync *current (119.97 Hz)
DRM state: head-0 mode: 120 396360 1920 1968 2000 2888 1080 1083 1088 1144

Effective Presentation Capped at ~60 FPS:
Despite DRM running the 396.36 MHz modeline, hardware VSync presentation (via glxgears, browsers, and desktop compositors) remains locked at ~60 FPS.
Running with vblank_mode=0 immediately unlocks rendering to 550–2,700+ FPS, confirming that 3D rasterization isn't the bottleneck.

3. Technical Investigation & Findings

Looking into the Nouveau kernel sources (dispnv50, nvkm/engine/disp, and nvkm/subdev/clk), a couple of architectural factors stand out:

DisplayPort 1.1a Bandwidth & 6 bpc Clamping:
The 396.36 MHz pixel clock at 8 bpc (24 bpp) requires ~9.51 Gbps, exceeding the 4-lane DP 1.1a HBR ceiling (8.64 Gbps).
In dispnv50/disp.c (nv50_outp_atomic_check_bpc), Nouveau correctly steps down color depth to 6 bpc (18 bpp, ~7.13 Gbps) with spatial dithering to fit the link.
Aggressive VBlank Power-Down (vblank_disable_immediate = true):
In dispnv50/disp.c, Nouveau aggressively powers down VBlank interrupts immediately between frames. We added a parameter to test continuous VBlank interrupt generation (vblank_continuous=1).
Internal Display Hub Clock (DISPCLK / hubk07 / hubk06):
On Fermi GPUs, scanout buffers are fetched through the internal display hub clocks (hubk07/hubk06).
In upstream Nouveau, hubk domains remain fixed to low boot-time frequencies (~100–200 MHz) and are not dynamically scaled up when high-dotclock display modes (e.g. 396 MHz) are requested.
We are testing dynamic scaling of hubk07/hubk06 up to 405 MHz during performance states (pstate 0f).

4. Discussion & Questions

Has anyone experimented with high-refresh (120Hz / 144Hz) panels on older NVIDIA GPUs (Fermi / Kepler) under Nouveau?
Are there known quirks with how Mesa's DRI3/Present loader and Xorg modesetting interact with high-pixel-clock eDP scanout under Nouveau?
What are your thoughts on linking CRTC pixel clock requirements with nvkm_clk display hub domains?

The project and documentation are available on GitHub for anyone interested in testing or contributing:
https://github.com/Twilight0/nouveau-fermi-reclock-dkms

AUR package:
https://aur.archlinux.org/packages/nouv … clock-dkms

Looking forward to your thoughts and insights!

twilight0 · 2026-08-30 08:57:30

Nouveau Fermi (GF106 / GT 555M) 120Hz & Reclocking Benchmark Results

Hardware: Dell XPS L702X, NVIDIA GeForce GT 555M (Fermi GF106M, 3GB DDR3), 1920x1080 @ 120Hz eDP panel (LGD 0x02c5).

glxgears Benchmark Results:

+------------------------------------+---------------+-------------------------+----------------------------------------+
| Driver & Session Setup             | VSync (FPS)   | Unthrottled (vblank=0)  | Renderer & Engine                      |
+------------------------------------+---------------+-------------------------+----------------------------------------+
| Qtile (Wayland / wlroots)          | 120.05 FPS    | 1,895.8 FPS             | NVC3 (Nouveau Hardware @ 590 MHz)      |
| Weston (Native Wayland EGL)        | 120.00 FPS    | 2,518.6 FPS             | NVC3 (Nouveau Hardware @ 590 MHz)      |
| NVIDIA Proprietary (390.157)       | 119.98 FPS    | ~1,650 - 1,800 FPS      | NVIDIA Proprietary Driver (Fermi)      |
| X11 / Xlibre (Patched Nouveau)     | 119.97 FPS    | 1,303.7 FPS             | NVC3 (Nouveau Hardware @ 590 MHz)      |
| Cinnamon (Wayland Preview)         | 60.64 FPS     | 781.6 FPS               | llvmpipe (CPU Software Fallback)       |
| Stock Nouveau (Unpatched)          | ~52 - 57 FPS  | ~380 - 450 FPS          | NVC3 (Stuck at 202 MHz base clock)     |
+------------------------------------+---------------+-------------------------+----------------------------------------+

Key Findings:

Parity with Proprietary Driver: Open-source Nouveau on Wayland (1,895.8 FPS) matches and slightly outperforms the legacy proprietary NVIDIA 390.157 driver (~1,700 FPS).
Wayland vs. X11: Native wlroots Wayland compositing yields a ~45% throughput boost over X11 (1,895 FPS vs 1,303 FPS).
True 120Hz VSync: Rock-solid 120.05 FPS hardware vertical refresh synchronization on the internal eDP panel.
4.5x Improvement Over Stock: Dynamic reclocking from 202 MHz to 590 MHz core / 900 MHz memory eliminates the Fermi performance penalty completely.

drankinatty · 2026-08-31 08:39:25

@twilight0 that is a much needed project and it sounds like you are looking a areas that needed much improvement. This is a follow up from the comment left at the AUR/Nvidia-390xx-utils page. I have nothing against the nouveau driver, I've used it before, from about the time of its first release. (with the old 9600 Twin-Turbo and 18800 single slot card)

I don't game, so for most of the time nouveau works well. However, when I use compiz/desktop-effects or the like, that is when you notice a huge performance difference. Nouveau has just never been able to provide the necessary performance, even with the Quadro 3000 on the laptop (256-bit bus) or the miscellaneous 240 (330 driver) 460 and 560 cards (390 driver) or the 980gtx cards (616 driver).

I guess the question going forward is whether the Noveau project proper is willing to pick up your improvements and incorporate them into the standard nouveau driver. Otherwise, it more a tradeoff between a highly patched nouveau driver or highly patch nvidia driver. And if we are going to the trouble to patch, I'll take the driver that gives the best performance. One thing nouveau can't do is provide an openCL type library to utilize the GPU for processing. The nvidia closed source driver provides openCL, it could use improvement, but does work.

Good luck with your project and I'll keep an eye on it.

twilight0 · 2026-08-31 08:42:28

The point is closed driver does not support Wayland, that's a deal breaker. I could use Xlibre/Xorg going forward but that requires endless patching for the kernel.

Arch Linux

#1 2026-08-29 06:52:49

Fermi (GF106) eDP 120Hz Display & Dynamic Reclocking on Nouveau

#2 2026-08-30 08:57:30

Re: Fermi (GF106) eDP 120Hz Display & Dynamic Reclocking on Nouveau

#3 2026-08-31 08:39:25

Re: Fermi (GF106) eDP 120Hz Display & Dynamic Reclocking on Nouveau

#4 2026-08-31 08:42:28

Re: Fermi (GF106) eDP 120Hz Display & Dynamic Reclocking on Nouveau

Board footer