[radeon] Display output laggy from iGPU when operating on desktop with attaching AMD R7 430 graphic (dGPU)

I tried to install hirsute daily build (495fe189e32d873ba79d7753134c22353ea89e8e6d62498f6c825a5de6a8a4a7) and didn't see this issue.

but the xorg might have some problems when using hirsute.

here is the result of $ xrandr -d :0 --prop
---
 PRIME Synchronization: 0
  supported: 0, 1
 GAMMA_LUT_SIZE: 4096
  range: (0, -1)
 DEGAMMA_LUT_SIZE: 4096
  range: (0, -1)
 GAMMA_LUT: 0
  range: (0, 65535)
 CTM: 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0
  0 1
 DEGAMMA_LUT: 0
  range: (0, 65535)
 TearFree: auto
  supported: off, on, auto
 subconnector: HDMI
  supported: Unknown, VGA, DVI-D, HDMI, DP, Wireless, Native
 HDCP Content Type: HDCP Type0
  supported: HDCP Type0, HDCP Type1
 Content Protection: Undesired
  supported: Undesired, Desired, Enabled
 vrr_capable: 0
  range: (0, 1)
 max bpc: 8
  range: (8, 16)
 underscan vborder: 0
  range: (0, 128)
 underscan hborder: 0
  range: (0, 128)
 underscan: off
  supported: off, on, auto
 scaling mode: None
  supported: None, Full, Center, Full aspect
 link-status: Good
  supported: Good, Bad
 CONNECTOR_ID: 80
  supported: 80
 non-desktop: 0
  range: (0, 1)
---

When issuing the same command on hirsute daily build, it shows
---
 non-desktop: 0
  range: (0, 1)
---
only.

Tried packages from https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers doesn't help.

When I attached another monitor to dGPU (which means connecting monitor to each iGPU and dGPU), then there is no problem.

Xorg actually doesn't have support for synchronizing multiple screens very well. The compositor can only paint all screens at once, and then the Xorg drivers have to output their areas at separate times later.

The 'modeset' Xorg driver will just sync to one and tear on the others. And I am not sure how radeon/amdgpu are expected to interplay. If they support a TearFree feature then that means at least one of them has to delay each frame, which you might see as lag. Also, if the monitors have different refresh rates then there's no guarantee Xorg will sync to the fastest one -- it might sync to the slowest, which has to be worked around in the drivers.

I suggest the first thing to investigate here is to see if you can get both GPUs using the same driver (from the kernel onward). Because using both 'radeon' and 'amdgpu' at the same time might be causing this.

GNOME Wayland sessions don't have this problem at all because there is no Xorg and it schedules each display separately.

What is the output from 'xrandr --verbose' ?

BTW, the FPS is 1.

$ DISPLAY=:0 glxgears
Running synchronized to the vertical refresh. The framerate should be
approximately the same as the monitor refresh rate.
344 frames in 5.6 seconds = 61.884 FPS
5 frames in 5.0 seconds = 0.997 FPS
6 frames in 6.0 seconds = 1.002 FPS
6 frames in 6.0 seconds = 1.000 FPS

---

I did confirm the i915(iGPU) + amdgpu(dGPU) could reproduce this issue as well.

Ooops, single monitor, I see.

Next we should probably verify whether it is mutter-specific or a general Xorg problem. Can you try a desktop that is not GNOME?

backport the patches from https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/460 doesn't help.

---

* d5016e5b61f96496f9b31d14eae16f5f0148b748 (HEAD -> backport-7-patches-from-Łukasz-sync_present_to_slave_outputs) Remove unused function ms_covering_xf86_crtc()
* d892481c2a3d67462f6d2c0d762c43b63cdcd45c xserver/output: rename some badly named variables/APIs.
* 1fb0dc09a60e97306088d75fefeed17a39e622ea (master) modesetting: Remove few common functions from ms namespace
* a1f28e05d602f5cde825111ca0654311c2aba73b modesetting: remove unnecessary ms_covering_xf86_crtc dup of ms_covering_randr_crtc
* d1b3204d1f1357426864c5125bf2ff8b84827d23 modesetting: Find crtc on secondary outputs as fallback instead of returning primary crtc
* 028688ba6dc50fbc6430812c608f69912e4196d4 randr: Fix link errors after previous commit
* 327441e28fa50fef18c0d15f377e61479fa956a4 present: fix msc offset calculation in screen mode
* 8477111ac5e3dee4066efc689d4507fa1b245900 present: Use crtc's screen present operation for syncing
* c271560a66d1d0a36dd7b784e75822ee00acc216 modesetting: Initialize present extension despite glamor is disabled
* 9f5b6b400462dd5b979c40361c4fcb35d08f9dd1 apt source xserver-xorg-core

@Daniel,

ok, let me try the other desktops.

BTW, the cursor moves smoothly but other operations laggy (e.g. move the terminal window).

XFCE has the same result.

I'm able to reproduce this issue on XFCE.

The attachments only show radeon and amdgpu, but at the top of the bug you said it happens with i915 too. I wonder if you could please verify that, and if it happens with i915 then please attach data from that machine:

  lspci -kv > lspci2.txt
  journalctl -b0 > journal2.txt

If we can see the same bug occurring with i915 then we might be able to exclude one of the AMD drivers and would be left with only a single driver to blame then...

@Daniel,

Above are the outputs.

Thanks. That shows 'radeon' is the common problem.

Also, is "AMD R7 430" a typo? Should that be "AMD R7 340"?

Hi Daniel,

The "AMD R7 430" is the product name of the graphic card.
https://ssl.www8.hp.com/emea_africa/en/products/oas/product-detail.html?oid=26185185

I guess it's related to radeon driver since we could see this issue with amd RX550 as well.

Another useful thing that would be easy to test: Does the same bug occur in hirsute?

BTW, for i915 case, it's not 100% reproduce if the boot-vga-device is i915.

Which means in Intel + AMD platform.

Sometime the system laggy when output from dGPU (AMD 430).
Sometime the system laggy when output from iGPU (intel) AFTER switching the monitor between dGPU and iGPU (e.g. boot vga: i915 -> moving monitor to dGPU -> moving monitor back to iGPU).

but all works smoothly when connecting two monitor from both iGPU and dGPU (this scenario works good on AMD + AMD platform).

Comment #19 is probably important to answer because we need to know if we're looking for a backport or a whole new upstream fix.

The other finding for comment#20.

If connecting two monitors then there is a way to reproduce it.

1. Set iGPU as primary monitor
2. Run an application from secondary display (dGPU) (e.g. glxgear)
3. Moving the application from secondary display (dGPU) to primary display (iGPU) then the issue occur.

For comment#19, I'm preparing hirsute using today daily build. Will update the result here later.

Hi Daniel,

I could reproduce this issue when using today hirsute daily build

$ sha256sum ~/Downloads/hirsute-desktop-amd64.iso
4908a5c919f4b796a856be69a044334eb1a910727180618348db0a8a1ef70360 /home/jeremysu/Downloads/hirsute-desktop-amd64.iso

after switching back to xorg (hirsute default uses Wayland)

As a workaround you should be able to avoid the radeon Xorg driver with a custom config, something like:

       Section "Device"
         Identifier "MyRadeon"
         Driver "modesetting"
         BusID "pci:1:0:0"
       EndSection

Then it will use the same interfaces as in a Wayland session.

Or just remove/edit /usr/share/X11/xorg.conf.d/10-radeon.conf

Combining the above two ideas you could add a new config file (make sure its name loads before "10-radeon.conf"):

Section "OutputClass"
 Identifier "MyRadeon"
 MatchDriver "radeon"
 Driver "modesetting"
EndSection

Hi Daniel,

Thanks for sharing comment#27.

Let me summarize the reproduce scenarios in Intel + AMD case.

1. Boot from iGPU -> switch to dGPU -> switch back to iGPU -> iGPU lag.
2. Boot from iGPU -> connect secondary monitor to dGPU -> remove 1st monitor from iGPU -> dGPU lag.
3. Boot from iGPU -> connect secondary monitor to dGPU -> set iGPU as primary display -> moving an application (e.g. glxgear) from secondary display (dGPU) to primary display (iGPU) -> iGPU lag.

The comment#27 could workaround case#1 and case #3.

but switch to wayland could fix these three cases.

I'm slightly worried you might be hitting multiple different bugs there. But instead of worrying, maybe just try the 'modesetting' driver. It might solve even more problems if you get both GPUs using the same driver:

Section "OutputClass"
  Identifier "Use Modesetting"
  MatchDriver "radeon|amdgpu"
  Driver "modesetting"
EndSection

I'm not sure why those drivers don't yet prefer "modesetting" by default because in Wayland sessions that's exactly what happens anyway.

@Daniel,

u@u-HP-EliteDesk-800-G6-Tower-PC:~$ dpkg -S /usr/share/X11/xorg.conf.d/10-radeon.conf
xserver-xorg-video-radeon: /usr/share/X11/xorg.conf.d/10-radeon.conf
u@u-HP-EliteDesk-800-G6-Tower-PC:~$ dpkg -S /usr/share/X11/xorg.conf.d/10-amdgpu.conf
xserver-xorg-video-amdgpu: /usr/share/X11/xorg.conf.d/10-amdgpu.conf

The radeon and amdgpu drivers are came from xserver-xorg-video-radeon/amdgpu.

xserver-xorg-video-radeon comes from xserver-xorg-video-ati
xserver-xorg-video-ati and xserver-xorg-video-amdgpu comes from xserver-xorg-video-all

Do you think we could remove both from xserver-xorg-video-all if the target is to use modesetting for amd gpu?

Or anything I can do to help to fix it?

I've subscribed Timo who should know why Ubuntu still prefers 'radeon' and 'amdgpu' Xorg drivers.

But also I am only guessing that my recommended config changes will fix the issue. It would be useful to test them too.

because the native drivers have features that modesetting_drv does not have, and how AMD expects them to be used

Good point. Running 'man amdgpu' I can immediately see one such good reason:

  Option "TearFree" "boolean"

Anyway, for this bug my thinking is that if a different config satisfies the OEM then that can be considered as a semipermanent workaround.

Other than that, it looks like the bug needs to be reported upstream to https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati

Hi Daniel,

Thank you for sharing.
We are not allow to provide a customization as workaround before we know the fix plan.

I reported an upstream issue:
https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/-/issues/194