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

Bug #1820832 reported by dreamcat4 on 2019-03-19
36
This bug affects 6 people
Affects Status Importance Assigned to Milestone
nvidia-graphics-drivers-418 (Ubuntu)
Undecided
Unassigned
xserver-xorg-video-amdgpu (Ubuntu)
Undecided
Unassigned

Bug Description

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) wrote :

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

Changed in gnome-shell (Ubuntu):
status: New → Confirmed
Mitch (midda) wrote :

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) wrote :

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

affects: gnome-shell (Ubuntu) → nvidia-graphics-drivers-418 (Ubuntu)
Daniel van Vugt (vanvugt) wrote :

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.

Changed in mutter (Ubuntu):
status: New → Invalid
tags: added: multimonitor
Changed in mutter:
status: Unknown → Fix Released
Changed in nvidia-graphics-drivers-418 (Ubuntu):
status: Confirmed → New
Mitch (midda) wrote :

Sure, here's my Xorg.log

dreamcat4 (dreamcat4) wrote :

> 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/

tags: added: nvidia
tags: added: performance
summary: - (xorg) multiple monitors: limits the framerate of faster 120/144hz
- monitors to 60hz
+ [nvidia] [xorg] multiple monitors: limits the framerate of faster
+ 120/144hz monitors to 60hz
Changed in nvidia-graphics-drivers-418 (Ubuntu):
status: New → Confirmed

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) wrote :

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

Mitch (midda) wrote :

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) wrote :

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.

no longer affects: mutter
summary: - [nvidia] [xorg] multiple monitors: limits the framerate of faster
- 120/144hz monitors to 60hz
+ [xorg] multiple monitors: limits the framerate of faster 120/144hz
+ monitors to 60hz
no longer affects: mutter (Ubuntu)
Launchpad Janitor (janitor) wrote :

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

Changed in xserver-xorg-video-amdgpu (Ubuntu):
status: New → Confirmed
Muhammed Ali Geldi (rankhole) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Bug attachments