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

[dreamcat4]

multiple monitors on xorg
=============================

Was recently discussed over on https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1763892

Another user + myself have the following issue:

The slowest connected display limits the FPS. The test case we used is over at the top of the other bug report ^^

This we found today happens with either amd vega graphics, or nvidia pascal graphics, the vendor doesn't seem to matter. We have both seen the same issue (xorg).

This is on 18.10, and booting into the 'Gnome (xorg)' login option. With the FPS being logged by journalctl -f. With only single monitor attached. Then it initially goes as high as the primary monitor can show. (And glmark2 running in background, to maintain a continued load). Which is 120fps for my case. Then as soon as secondary monitor is plugged in, which is a 60hz TV. This is being plugged into the HDMI port of the same graphics card in real time. Then the FPS logged by 'journalctl -f' drops, and becomes capped to 60hz, in the output being printed by journalctl -f.

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

mutter version:

mutter/cosmic-updates,now 3.30.2-1~ubuntu18.10.4 amd64 [installed]
mutter-common/cosmic-updates,cosmic-updates,now 3.30.2-1~ubuntu18.10.4 all [installed]

To confirm where the '.4' at the very end of the ~ubuntu18.10.4 version number, it seems to be that we have updated now on our client machines the be most recent bugfix updates, kindly provided by Daniel. Which closed the other bug https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/1763892 being referred to, as being solved for people's single monitor scenarios.

Thanks again for the other recent bug fixes in this area, it is a nice progress. Very helpful! We hope you can also look into this latest problem / issue for the multiple monitor scenario.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Mitch (midda)]

Just confirming that this issue affects me also. Here's my post from the other other bug:

I'm using Xorg with an AMD Vega 64. Both displays are connected to the GPU. My main 144hz display is connected via Display Port, and my second 60hz display is connected via HDMI.

I'm using Mesa 19.1.0-devel - padoka PPA

When I perform the test case in the first post, I get high framerates when the secondary display is disabled, and only 60 fps when it's enabled.

[Daniel van Vugt (vanvugt)]

This is a bug/limitation of the graphics driver itself. So I will reassign this bug to NVIDIA.

Also Mitchell, please let us know which AMD Xorg graphics driver you are using (attach a Xorg.log?).

As luck would have it, one user upstream found a solution for NVIDIA documented here:

https://gitlab.gnome.org/GNOME/mutter/issues/503#note_463305

[Daniel van Vugt (vanvugt)]

dreamcat4,

NVIDIA driver version 415 doesn't exist in Ubuntu so we can't log bugs against that. I have instead logged it against version 418, assuming the problem is still there.

[Mitch (midda)]

Sure, here's my Xorg.log

[dreamcat4 (dreamcat4)]

> As luck would have it, one user upstream found a solution for NVIDIA documented here:
>
> https://gitlab.gnome.org/GNOME/mutter/issues/503#note_463305
>

Hello. Tried this suggestion today (setting "__GL_MaxFramesAllowed=1" in /etc/environment, and rebooting). It might have decreased my CPU usage, I am not certain. However what I am sure of is that it does no fix the 60hz framerate issue with multiple monitors, on NVIDIA.

So have now reported the bug over on NVIDIA's forum. With links back to here:

https://devtalk.nvidia.com/default/topic/1049107/linux/-linux-xorg-multiple-monitors-limits-the-framerate-of-faster-120-144hz-monitors-to-60hz/

[Mitch (midda)]

For AMD users, I finally managed to get my primary display to correctly update at 144Hz under Xorg by manually enabling TearFree rendering, as described here:

https://wiki.archlinux.org/index.php/AMDGPU#Tear_Free_Rendering

I manually created the file:
/etc/X11/xorg.conf.d/20-amdgpu.conf

Inside it, I added:

Section "Device"
     Identifier "AMD"
     Driver "amdgpu"
     Option "TearFree" "true"
     Option "VariableRefresh" "true"
EndSection

Then rebooted, and everything was -finally- nice and smooth! :D

Note that I added the "VariableRefresh" option because my monitor supports FreeSync. Don't include that line if your monitor doesn't support variable refresh-rates.

[Daniel van Vugt (vanvugt)]

This bug is about Nvidia only so please discuss AMD elsewhere.

[Mitch (midda)]

The original description specifically mentions both Nvidia and AMD cards being affected, as the bug was based on the experiences reported by myself and dreamcat4 in the bug for Mutter capping the FPS to 60.

In fact, you specifically asked me to post my Xorg log file for my AMD card, which I did a month ago.

[Daniel van Vugt (vanvugt)]

Yes, sorry. I am trying to track hundreds of bugs in my head and I don't always remember (or reread) the context of each one every day.

I have now modified the task list for this bug so it tracks both Nvidia and AMD drivers.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Muhammed Ali Geldi (rankhole)]

I can also confirm that this bug is still present. I'm on Ubuntu 19.04 with the latest drivers & updates installed.

Also, I want to add something hereeeee: It's not that it specifically limits the framerate to 60 Hz. Rather, it limits it to the monitor with the lowest refresh rate. Try setting one monitor's refresh rate to 30 Hz, and you should instantly notice how laggy the whole desktop environment becomes.

I understand that this issue might be looked at as "not that important", but I believe a lot of people that would love to switch from Windows to something like Ubuntu really wouldn't appreciate the fact that their 144 Hz monitor doesn't work as intended. If you own one yourself, you probably would never want to set it to 60 Hz out of free will.

[Rafael Rion (rafarion)]

I can confirm this bug too. But additionally I have noticed one more interesting fact:

It seems that this bug affects only PCs with dedicated GPUs (AMD, Nvidia). When I connect monitors into motherboard ports this bugs disappears. In my case via VGA(60Hz) and DVI-D(120Hz), but I believe that with HDMI and DisplayPort there will be the same results as with VGA or DVI. Unfortunately I haven't got a motherboard with DP or HDMI to test it.

Because of this behaviour I have a theory that the bug exists only in Nvidia/AMD drivers for dedicated GPUs. I have got i5-4590 with integrated GPU and with this setup (without GPU) everything works fine.

[dreamcat4 (dreamcat4)]

well by that logic, then somebody with an amd ryzen APU (such as 3200G or whichever with the integrated Vega graphics). Would also not be affected by this bug.

But the other reason would be that intel's linux igp drivers are not affected. That is a different reason as to whether the gpu is being recognized as being discrete (or perhaps egpu) or not.

[Rafael Rion (rafarion)]

Good point, then there can be 2 explanations:

1) dedicated vs integrated GPU
2) intel vs amd/nvidia

I will try to get some AMD APU to test it.

[dreamcat4 (dreamcat4)]

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:

[x] "Sync to VBlank"
[ ] "Allow Flipping"
[x] "Allow G-SYNC/G-SYNC Compatible"
[x] "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.

[Eliastik (eliastik)]

Hello,

In my case, appending __GL_SYNC_DISPLAY_DEVICE=DP-0 in the /etc/environment file (DP-0 is my 144hz monitor - see X Server XVideo Settings in NVIDIA X Server Settings) seems to works (config: GTX 1070/60 Hz + 144 Hz monitors).

I forced resolution + frequency in NVIDIA X Server Settings for the two monitors in the X Server Display Configuration section.
Disabled Force Composition Pipeline + Force Full Composition Pipeline.
Disabled Sync to VBlank + Allow Flipping (OpenGL Settings).

NVIDIA driver version: 435.21 (the latest in Ubuntu 18.04.3 with HWE enabled).

[Eliastik (eliastik)]

Additionnal note for the previous comment: it also works when Sync to VBlank is enabled (tested with glxgears), but causes tearing for the 60 hz monitor.

[dreamcat4 (dreamcat4)]

Thanks for pointing that out because.... I also had __GL_SYNC_DISPLAY_DEVICE=DP-0 in /etc/environment as completely forgot to mention that in my previous comment to yours here.

[Pavel Sotnikov (inkognitoo)]

Hello,

I'm also have this bug.
Ubuntu 20.04.1 LTS

Video card - gtx 1070
I'm install 450.57 nvidia driver, but it doesn't help.

I have two monitors - Dell 60hz and Acer 144hz. If Dell is turn on, Acer enforce to 60hz.

If you need any additional information, I can add any.

[dreamcat4 (dreamcat4)]

Did you see it work on previous ubuntu version (19.10)? Or is 20.04 the first version you tested here?

[Pavel Sotnikov (inkognitoo)]

Hello, dreamcat4!

20.04 is only version I tested this case

[Eugene86 (eugene86)]

I confirm this issue on Ubuntu 20.04 LTS; Nvidia driver 440.100; Linux kernel 5.4.0-42-lowlatency; GeForce 1060 6GB
Two monitors: LG 27GL850 (144Hz DP connection) and Asus VG248 (60 Hz single-link DVI connection, despite display could more)
If the second (slow) display is connected "effective" refresh rate on first (fast) display is limited to 60 Hz. I mean effective, despite xrandr shows 140, actual window moving traces, effects in 3D games are similar to 60 Hz, and testufo.com also shows 60Hz. If I disable slow display in nvidia-settings, effective refresh rate (window moving, games) are smooth as supposed to be, and ufotest shows 144 Hz and smooth ufo moving.
I remember that there were no such issues with some previous version of nvidia driver (3xx)

[Daniel Prilik (prilik)]

I've also run into this issue on Pop!_OS 20.04 LTS; Nvidia driver 450.66; Linux kernel 5.4.0-7642-generic; GeForce GTX 1080 8GB; mutter 3.36.4; GNOME Shell 3.36.4.

I'm running two monitors: NS-PMG278 (144Hz DP connection) + Dell U2719D (60Hz DP connection), both at 1440x2560.

I'm getting the exact same symptoms as seppel. Updating /etc/environment with __GL_SYNC_DISPLAY_DEVICE doesn't seem to help either.

[dreamcat4 (dreamcat4)]

It would be nice to understand what is going on here. Currently on 19.10 and have not upgraded to 20.04 yet... because of this very same bug! It took so long to get rid of the last time around. Many months.

Should also do a regression test here back on 19.10 too? It seems I can install both the latest kernel v5.8.11 and the nvidia drivers are currently at 450.57 (on this system).

Looking to re-test here soon... also need to remember / check my version of gnome shell (xorg). It seems to be this one?

gnome-shell/eoan-updates,now 3.34.3-1ubuntu1~19.10.1 amd64 [installed]

According to my machine those are all now fully up to date, for what is currently available on the ubuntu 19.10 release. All these above as of today ^^. With 0 pending updates. Oh wait... mutter version?

libmutter-2-0/now 3.28.3-2~ubuntu18.04.2 amd64 [installed,local]
  window manager library from the Mutter window manager

libmutter-5-0/eoan-updates,now 3.34.3-1ubuntu1~19.10.1 amd64 [installed,automatic]
  window manager library from the Mutter window manager

mutter/eoan-updates,now 3.34.3-1ubuntu1~19.10.1 amd64 [installed]
  Example window manager using GNOME's window manager library

Will come back with the testing results in my next comment. After a clean boot into gnome shell etc.

[dreamcat4 (dreamcat4)]

OK I have now regression tested on the latest 19.10, with the above ^^software stack. All except incrementing the kernel from 5.8.11 to 5.8.13.

I can now confirm that the old bug has also re-appeared on 19.10 too. So it is not only exclusive to 20.04.

To myself, I really don know what to try. But I had been holding off upgrading to 20.04 only because of this bug. Daniel - do you need me for any more testing on 19.10? So i may be free to upgrade? Thank you for letting me know.

My opinion would be first try rolling back the nvidia driver stack, to a version that was latest at the time when we last confirmed this bug was fixed.

I.e.

nvidia-driver-450/eoan,now 450.57-0ubuntu0~0.19.10.2 amd64 [installed]
  NVIDIA driver metapackage

Roll that back.

Hopefully we can do this still on 20.04? Is that older package going to still work on 20.04? Thanks again! Please get back in touch.

[Daniel van Vugt (vanvugt)]

dreamcat4,

Ubuntu 19.10 is not supported. It reached end of life on July 17, 2020.

This is a bug/design feature of Xorg graphics drivers like Nvidia and AMD's. You can work around it either by explicitly configuring the driver to sync to the fastest monitor, or by enabling "TearFree" if available.

For a more long term permanent solution, using GNOME Wayland sessions should never hit such a problem. But that also requires your graphics driver support Wayland sessions :(