2560x1440@144Hz not running at full 144Hz with "force composition pipeline" enabled

I rather meant with vsync on, to check if there’s some odd throttling while using the compo pipeline.

Ah sorry, here:

No force pipeline, kwin compositing on with vsync on
70009 frames in 5.0 seconds = 14001.599 FPS
70751 frames in 5.0 seconds = 14150.053 FPS

Force pipeline only on main monitor, kwin compositing on with vsync on
68720 frames in 5.0 seconds = 13743.832 FPS
69476 frames in 5.0 seconds = 13895.100 FPS

Force pipeline on both monitors, kwin compositing on with vsync on
65737 frames in 5.0 seconds = 13147.360 FPS
65943 frames in 5.0 seconds = 13187.772 FPS

Those are rather odd values, should be the monitor’s refresh rate.
Does
export | grep GL
show any unsual variables?

No output.

I tried toggling the “sync to vblank” setting on in the control panel under X screen → OpenGL settings. It makes glxgears run at a stable 144 FPS even with force pipeline on. Everything still feels suggish though. I also tried logging out and back in with the setting saved, no luck.

In the past, I’ve always had “sync to vblank” off and “force full composition pipeline” on using two 1920x1080 displays. Just to reiterate, everything works fine with force pipeline on with the latest driver if I set the resolution to 1920x1080 on the 2560x1440 display.

Correction: I did some tests again and 1920x1080@144Hz with force pipeline seems to only work correctly over DVI. Even just 1920x1080@144Hz over HDMI or DP is no good.

This leads me to believe that it’s not actually the resolution, but the connection. I imagine if DVI supported 2560x1440@144Hz it would work. I wonder why the connection would be the problem.

To recap, the issue now seems to be the force pipeline setting not playing nice over DP or HDMI at high refresh rates. This really does sound like a driver bug. Is there a way to let NVIDIA know directly or am I already in the right place?

It’s the right place, though visual effects that can only be observed when sitting in front of a unique system are often neglected. Though I wonder why no other user reported this so far. It’s not that this is a very special setup.
Just to rule out any cross-effects from Kwin, did you try switching to something simple, like openbox?

I actually used to run openbox and still had my configs around! Unfortunately the issue persists even there.

I’d also be curious to hear if anyone else has had similar issues. Maybe people who aren’t used to high refresh rate displays don’t notice the problem. Like it still feels better than 60Hz but having used a 144Hz display for 4-5 years now it’s obvious that something is wrong. Or, maybe people don’t use the force pipeline options.

Since Openbox can be considered as bare Xserver + some menus, any side-effects from WM can be ruled out.
Since in your first nvidia-bug-report.log no Xorg logs and config files were included, can you please recreate it? Maybe this time they’re included and somthing odd is visible.

I made a new one and had a quick glance at it but didn’t see an Xorg log in it. Are these what you’re looking for?
Xorg.0.log (34.2 KB)
xorg.conf (1.6 KB)

Here’s the log anyway:
nvidia-bug-report.log.gz (199 KB)

Nothing unusual in xorg.conf but as soon as ForceCompositionpipeline gets enabled, Xorg log reports slowdowns, also dmesg reports it. No excessive irqs, though.
You have nvidia-drm.modeset=1 enabled on kernel command-line, shouldn’t make a difference but please check if anything changes when you disable it.
Also check for module options files:
https://forums.developer.nvidia.com/t/ubuntu-18-04-3-blank-screen-at-startup-with-430-drivers-and-gtx-960/107501/2?u=generix

I set the kernel option after reporting the issue in an attempt to solve an unrelated problem. I also checked /etc/modprobe.d and /lib/modprobe.d, no files containing that option. I’ll just remove it since it didn’t work out anyway.

Ok, do you see anything in ‘top’ eating much cpu when moving windows?

No real difference. Around 5% on kwin and 2% on Xorg, force pipeline on or off. Everything else is insignificant.

Real mystery, slowdowns reported but no cause. I guess you’ll have to wait for other users reporting the same.

That’s a shame but I guess there’s not much else I can do for now. Anyway, thank you for your time at least.

Update

On the latest driver (460.32.03), “force composition pipeline” now works correctly if the second monitor is disabled, or more interestingly, if I lower the resolution to 1920x1080@144Hz on the main monitor. Previously the latter only worked if the monitor was connected over DVI but now it seems to work just fine over DP.

Is there anything I could do to help find out why 2560x1440@144Hz with a second monitor connected still feels sluggish when “force composition pipeline” is enabled? I tried lowering the resolution and refresh rate of the second monitor, as well as only enabling “force composition pipeline” on the main monitor but no luck.

Update again

On the latest driver (460.67), everything works as expected even with second monitor on, but only up to 120Hz. Almost there, the drivers seem to be slowly improving!

I just wanted to state here that I have had a very similar problem.
I am currently using driver version 495.44 on Linux with a GTX 3080 with two 4k 60hz displays via displayport 1.2 and 1.4 (LG 27UK850 and LG 27UL850).
I get terrible screen tearing that is apparent even while scrolling on web pages.
When I activate force composition pipeline, the screen tearing is fixed, but the apparent framerate drops to 30Hz (confirmed with framerate comparison videos on youtube). Reported framerate in games is at 60Hz.
When I reduce the display resolution to 2560x1440 or switch to HDMI, force composition pipeline works as intended and there is no apparent loss of framerate.

I had kind of forgotten about this but I’ll give another update. According to my earlier posts, everything was working fine if I disabled the second monitor. However, now no matter what, if “force composition pipline” is enabled on the 2560x1440 monitor, it looks very choppy at 144 Hz. If I set both to 120 Hz it’s good but it would be a shame to throw away those extra frames.

This is on driver 470.86 because 495 has that dbus log spamming issue, though I don’t think it was any different on that version when I briefly tried it.