[linux+xorg] multiple monitors: limits the framerate of faster 120/144hz monitors to 60hz

Graphics / Linux Linux
1

multiple monitors on xorg

Was recently discussed over on ubuntu launchpad bug tracker. The new bug we would like for you to look at (over there) is:

Problem:

The slowest connected display limits the FPS. The test case we used, is described at the top of this page: @ https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1763892 (which is an older bug report, for some other fixes).

This specific problem has recently been investigated by Daniel. Who now believes that there may be a issue in the NVIDIA graphics driver. Which was not visible previously due to other masking / hiding bug (now solved).

My setup:
kernel 5.0.0-050000-lowlatency #201903032031
NVIDIA Driver for UNIX platforms 415.27 (the closed source one)
ubuntu 18.10

This bug only occurs with multiple monitors plugged in, of different refresh rates. If the 2nd (60hz) monitor is unplugged. Then the FPS of the primary monitor recovers and goes back up to it’s maximum rate of 120/144fps.

Have carefully tried all the other suggested solutions / workarounds. However none of them work. So we hope you can also look into this latest problem / issue, specifically for the multiple monitor scenario on Xorg. Since nobody from NVIDIA has been assigned to the bug yet! Thank you.

2

Might be due to this regression/feature removal:
[url]https://devtalk.nvidia.com/default/topic/1028347/linux/__gl_sync_display_device-regression-from-387-34-to-390-12/[/url]

3

Hello again. There has be no activity whatsoever on this bug report, and for several weeks. Just wanted to come back today to say I have updated again to the newest drivers and linux kernel version. Problem still exists. And this issue is unlikely to be fixed, until this matter is looked into.

[id:~] 130 $ uname -a
Linux apex 5.1.2-050102-lowlatency #201905141830 SMP PREEMPT Tue May 14 18:35:40 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

[id:~] $ apt search nvidia-driver | grep -i installed
nvidia-driver-430/cosmic,now 430.09-0ubuntu0~gpu18.10.1 amd64 [installed]
xserver-xorg-video-nvidia-430/cosmic,now 430.09-0ubuntu0~gpu18.10.1 amd64 [installed,automatic]

4

Are you using either ‘ForceFullCompositionPipeline=On’ or ‘ForceCompositionPipeline=On’? If so, does removing those options change the behaviour regarding refresh rates?

5

Yes, yes, no, no.

To be clear: The relevant open source developer over on ubuntu / gnome project (Daniel) has already looked into his side of the code over there. And has determined that their side of these issues have now been resolved. His opinion was further that there is some remaining issue(s) on the side of the nvidia graphics drivers for linux. And this is something which can only be taken further by an nvidia engineer or engineer(s).

The reported FPS by journalctl is shoing an fps no greater than 65fps maximum, but usually it is around 60-62fps. FWIW this seems to be some value that is calulated to be slightly in excess of the targetted framerate of 60fps, of the 2nd monitor (a TV). Which is then being drawn up on the 120fps primary monitor (as) 61fps. Or 62fps / whatever.

Here is a log showing the output according to test case, which I just took a few minutes ago.

My only suggestion at this point is to contact / bring better to the attention of nvidia engineers. For the closed source linux driver. And remain available for further testing.

Or otherwise please get in contact with Daniel about this, who is stationed over on the ubuntu / launchpad bug tracker site. Kind Regards.

6

Hello there. Good news for a change:

Re-tested this bug today on latest linux 5.3.1 kernel and nvidia 435.21 binary (closed) drivers. And it seems like there might be some improvement now.

What I noticed this time:

  • Enabled 120hz overclock on my high refresh 120hz monitor, and rebooted this monitor. It is my primary display.
  • Opened nvidia settings (“NVIDIA X Server Settings”)
  • Set the frame rate of this dispaly in there to 120hz with force full composition pipeline both on
  • Frame rate was initially capped at 60 fps. Which matches the slower 2nd monitor as before. As shown by the command: ‘sudo journalctl -f’
  • Then I unplugged my 2nd slower 60hz monitor.
  • Frame rate was still capped at 60 fps
  • Closed some graphical (probably open GL based) programs: Glxgears, kodi, and bitwig studio.
  • Frame rate was now capped to 71 fps
  • Went back to NVIDIA settings GUI
  • Navigated to “OpenGL Settings” page
  • Un-checked all of the first 4 settings on that page, which were:

“Sync to VBlank”
“Allow Flipping”
“Allow G-SYNC/G-SYNC Compatible”
“Enable G-SYNC/G-SYNC Compatible Visual Indicator”

  • The fps shown in ‘sudo journalctl -f’ is now going all the way up to 120hz. Whilst running the command ‘glxgears’ to make a graphical workload

I then went back and re-enabled all of the options in the OpenGL page, except for “Allow Flipping”, like this:

“Sync to VBlank”
“Allow Flipping”
“Allow G-SYNC/G-SYNC Compatible”
“Enable G-SYNC/G-SYNC Compatible Visual Indicator”

  • The frame rate was still reaching up to 120Hz.
  • Then I plugged my 2nd slower 60hz monitor back into the NVIDIA graphics card
  • Previously this was the point in the test when the frame rate would immediately drop back down to only 60 FPS

However this time, it stayed at 120fps. Which is very encouraging and a positive result from my testing today.

What I am not sure about:

  • How easily it is to get the system into this state
  • For example whether it can come up like this after a reboot. Or if it requires a certain ritual / ceremony / fernagaling to get everything to this point
  • How stable this state is, how delicate / easily broken by launching some specific program(s).

In particular I am thinking about fullscreen games. However my gpu here (GT 1030) simply isn’t powerful enough to do proper testing for more demanding programs and workloads like that.

Anyhow I think it’s a great result from what we can observe so far. Just wish I had a better graphics card now.