picom icon indicating copy to clipboard operation
picom copied to clipboard
verified publisher icon yshui

Performance degradation after waking up from Suspend with Linux Kernel 6.7

Open anthony-S93 opened this issue 1 year ago • 7 comments

Platform

OS: Arch Linux x86_64 Kernel: 6.7 arch3-1

GPU, drivers, and screen setup

GPU: AMD Radeon 680M Driver: xf86-video-amdgpu Setup: Laptop screen + 2 monitors (configured side-by-side with xrandr)

$ glxinfo -B
name of display: :0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: AMD (0x1002)
    Device: AMD Radeon Graphics (radeonsi, rembrandt, LLVM 16.0.6, DRM 3.54, 6.6.13-1-lts) (0x1681)
    Version: 23.3.3
    Accelerated: yes
    Video memory: 1024MB
    Unified memory: no
    Preferred profile: core (0x1)
    Max core profile version: 4.6
    Max compat profile version: 4.6
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.2
Memory info (GL_ATI_meminfo):
    VBO free memory - total: 375 MB, largest block: 375 MB
    VBO free aux. memory - total: 7325 MB, largest block: 7325 MB
    Texture free memory - total: 375 MB, largest block: 375 MB
    Texture free aux. memory - total: 7325 MB, largest block: 7325 MB
    Renderbuffer free memory - total: 375 MB, largest block: 375 MB
    Renderbuffer free aux. memory - total: 7325 MB, largest block: 7325 MB
Memory info (GL_NVX_gpu_memory_info):
    Dedicated video memory: 1024 MB
    Total available memory: 8399 MB
    Currently available dedicated video memory: 375 MB
OpenGL vendor string: AMD
OpenGL renderer string: AMD Radeon Graphics (radeonsi, rembrandt, LLVM 16.0.6, DRM 3.54, 6.6.13-1-lts)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 23.3.3-arch1.1
OpenGL core profile shading language version string: 4.60
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 4.6 (Compatibility Profile) Mesa 23.3.3-arch1.1
OpenGL shading language version string: 4.60
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile

OpenGL ES profile version string: OpenGL ES 3.2 Mesa 23.3.3-arch1.1
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

Environment

No desktop environment. Only a window manager (i3wm)

picom version

$ picom --version
vgit-197b4
Diagnostics 
$ picom --diagnostics
**Version:** vgit-197b4

### Extensions:

* Shape: Yes
* RandR: Yes
* Present: Present

### Misc:

* Use Overlay: No
  (Another compositor is already running)
* Config file used: /home/anthony93/.config/picom/picom.conf

### Drivers (inaccurate):

AMDGPU, Radeon

### Backend: glx

* Driver vendors:
 * GLX: Mesa Project and SGI
 * GL: AMD
* GL renderer: AMD Radeon Graphics (radeonsi, rembrandt, LLVM 16.0.6, DRM 3.54, 6.6.13-1-lts)
* Accelerated: 1

### Backend: egl

* Driver vendors:
 * EGL: Mesa Project
 * EGL driver: radeonsi
 * GL: AMD
* GL renderer: AMD Radeon Graphics (radeonsi, rembrandt, LLVM 16.0.6, DRM 3.54, 6.6.13-1-lts)

Configuration:

Configuration file 
#################################
#             Shadows           #
#################################


# Enabled client-side shadows on windows. Note desktop windows
# (windows with '_NET_WM_WINDOW_TYPE_DESKTOP') never get shadow,
# unless explicitly requested using the wintypes option.
#
shadow = false

#################################
#           Fading              #
#################################


# Fade windows in/out when opening/closing and when opacity changes,
#  unless no-fading-openclose is used.
fading = false;

#################################
#   Transparency / Opacity      #
#################################

# Opacity of inactive windows. (0.1 - 1.0, defaults to 1.0)
inactive-opacity = 1;

# Opacity of window titlebars and borders. (0.1 - 1.0, disabled by default)
frame-opacity = 1;

# Let inactive opacity set by -i override the '_NET_WM_WINDOW_OPACITY' values of windows.
inactive-opacity-override = false;


#################################
#       General Settings        #
#################################

backend = "xrender";

Detailed description of issue

After waking my system from suspend, there is a noticeable performance drop in the rendering of windows. Here is a video to illustrate this:

https://github.com/yshui/picom/assets/69449791/c7009625-5241-4540-8fc4-fe570c3c05d1

The video above shows my attempt to launch new instances of the alacritty terminal after I woke my system up from suspend. The lag manifested itself as a noticeable flicker in the terminal window's transparent background.

Here is how the drawing of the terminal window looked like before I put my system into suspend.

https://github.com/yshui/picom/assets/69449791/a0cef685-4e08-41b7-afba-4209e679a947

Although there is still a flicker, but it isn't as obvious.

Note that every time the lag occurred, I could make it go away by killing picom with pkill picom . This made me suspect that the compositor was slowing down the drawing of the windows.

Please also note the following important details:

  1. ~As long as picom is restarted after waking up from suspend, the lag will not occur. I tried this many times either by restarting X server (which will obviously launch a new instance of picom due to my i3 config) or restarting picom. The lag did not appear in either case. But if I did neither after waking up from suspend, the lag would be there.~ The lag goes away if I restart X server after waking up the system from suspend.
  2. The lag only occurs when there are multiple windows opened in the session. E.g: if I close all application windows (without restarting picom after waking up from suspend, obviously) before launching the alacritty terminal, no lag will occur.

Things I've tried so far

  1. Downgraded mesa (did not work) At first, I thought a botched mesa upgrade was the culprit. However, the issue was still reproducible after I downgraded mesa as far back as version 23.1
  2. Downgraded alacritty (did not work)
  3. Downgraded Linux kernel to 6.6 (worked) This issue does not occur with any version of the Linux kernel prior to 6.7. With kernel 6.6, I can wake my system up from suspend as many times as I want without experiencing any lag in the opening of new windows. For some reason, picom doesn't seem to play well with the latest kernel.

Steps of reproduction

  1. systemctl suspend
  2. Wake up from suspend
  3. Make sure to have at least two application windows opened.
  4. Launch an alacritty instance

Expected behavior

The drawing of the alacritty's terminal window should be seamless and smooth (like it has always been).

Current Behavior

There was a noticeable lag in the drawing of the terminal window, which manifested itself as a flicker (see video above).

OpenGL trace

I tried to use apitrace as suggested in the wiki but to no avail. There was no picom.trace file in the current working directory after the picom instance was killed. I did, however, capture the logs with the --log-level=trace flag.

While capturing these log files, I had 2 firefox windows and 1 thunar window open. I then tried to compare the visual differences when launching new alacritty terminal windows before and after suspend.

log-before-suspend log-after-waking-up-from-suspend

anthony-S93 avatar Jan 23 '24 16:01 anthony-S93

do you have a reason to use the xrender backend?

absolutelynothelix avatar Jan 23 '24 16:01 absolutelynothelix

do you have a reason to use the xrender backend?

glx has always been slower on my system compared to xrender. And it seems that other users noticed this as well #620

The issue described above affects both glx and xrender backends. The only difference is that with glx, the lagging is much more pronounced to the point where it rendered the entire graphical environment pretty much unusable (even typing and scrolling became laggy). I wish I was able to record my screen when this occured, but like I said, the system was so laggy that it was impossible for me to do anything other than use SysReq.

anthony-S93 avatar Jan 23 '24 17:01 anthony-S93

hm, what about legacy backends? does --legacy-backends --backend=xrender have the same issue and is performance with --legacy-backends --backend=glx bad? you could also try the new egl backend (--backend=egl) but i doubt that it’ll differ from glx for you.

absolutelynothelix avatar Jan 23 '24 17:01 absolutelynothelix

hm, what about legacy backends? does --legacy-backends --backend=xrender have the same issue and is performance with --legacy-backends --backend=glx bad? you could also try the new egl backend (--backend=egl) but i doubt that it’ll differ from glx for you.

I just tested egl. You are correct. egl's performance is about the same as glx on my system.

I also conducted further tests with hyperfine 'alacritty -e false.

# Before suspend (picom, Linux 6.7) 
Time (mean ± σ):     162.7 ms ±   8.8 ms    [User: 66.6 ms, System: 45.4 ms]
  Range (min … max):   145.4 ms … 181.2 ms    18 runs

# After suspend (picom, Linux 6.7)
Time (mean ± σ):     259.1 ms ±  38.0 ms    [User: 66.0 ms, System: 45.6 ms]
  Range (min … max):   227.3 ms … 364.0 ms    13 runs

# After suspend (without picom, Linux 6.7)
A lot slower. Had to kill the process with Ctrl+C

# Before suspend (picom, Linux 6.6)
Time (mean ± σ):     161.1 ms ±  12.8 ms    [User: 63.8 ms, System: 41.9 ms]
  Range (min … max):   146.2 ms … 181.3 ms    18 runs

# After suspend (picom, Linux 6.6)
Time (mean ± σ):     156.5 ms ±  13.8 ms    [User: 65.8 ms, System: 41.6 ms]
  Range (min … max):   129.7 ms … 179.0 ms    16 runs

# After suspend (no picom, Linux 6.6)
Time (mean ± σ):     155.4 ms ±  11.4 ms    [User: 66.9 ms, System: 42.2 ms]
  Range (min … max):   132.4 ms … 177.3 ms    17 runs

I should note that with Linux 6.7 after suspend, when the benchmarking was performed without picom, the results were actually slower. The issue lies with the new kernel, it seems.

anthony-S93 avatar Jan 23 '24 17:01 anthony-S93

do you have a reason to have xf86-video-amdgpu installed? these packages tend to create more problems than solve. could you remove it, reboot and test both issues (xrender performance after suspension and glx performance)?

i’ll refer to your issues as xrender issue and glx issue from now on

absolutelynothelix avatar Jan 23 '24 22:01 absolutelynothelix

do you have a reason to have xf86-video-amdgpu installed? these packages tend to create more problems than solve. could you remove it, reboot and test both issues (xrender performance after suspension and glx performance)?

Thanks for the suggestion. I have it installed because it is the only way to get rid of screen tearing on my system. Despite the claim that the TearFree option is now available in the modesetting driver, the TearFree option does not work. Here is a snippet of Xorg log:

X.Org X Server 1.21.1.11
X Protocol Version 11, Revision 0
.
.
.
[   665.434] (II) LoadModule: "modesetting"
[   665.434] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[   665.435] (II) Module modesetting: vendor="X.Org Foundation"
[   665.435] 	compiled for 1.21.1.11, module version = 1.21.1
[   665.435] 	Module class: X.Org Video Driver
[   665.435] 	ABI class: X.Org Video Driver, version 25.2
[   665.435] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
.
.
.
[   665.504] (WW) modeset(0): Option "TearFree" is not used
[   665.504] (II) modeset(0): [DRI2] Setup complete

As you can see, the TearFree option wasn't even used despite the fact that it is now available for modesetting.

Regardless, it was indeed as you predicted. The post-suspend xrender issue went away after I tested the modesetting driver with Kernel 6.7

But now because I have uninstalled xf86-video-amdgpu I'm left with screen tearing. Is there a way to remove screen tearing using picom itself? (Update: I found out how to do this. Added vsync = true to my picom config and the tearing went away).

I will test the system for a few more days before closing this issue.

Update:

As it turns out, I was wrong. The issue returned even with the modesetting driver after I suspended the system for a longer period of time.

https://github.com/yshui/picom/assets/69449791/4647cb94-f479-4b2b-baca-3d7f05207d8d

The lag goes away after I killed picom.

https://github.com/yshui/picom/assets/69449791/2165e062-24e1-4994-a8fd-1ee5264924a5

To summarize, these are the behavior of my system after waking up from suspend under various conditions: modesetting + kernel 6.7 + picom (glx) = lag, but still usable (lag goes away immediately after killing picom) modesetting + kernel 6.7 + picom (xrender) = lag, but still usable (lag goes away immediately after killing picom) modesetting + kernel 6.6 + picom (glx) = no lag modesetting + kernel 6.6 + picom (xrender) = no lag amdgpu + kernel 6.7 + picom (glx) = lag, unusable (lag goes away after killing picom from tty) amgdpu + kernel 6.7 + picom (xrender) = lag, but still usable (lag goes away immediately after killing picom) amgdpu + kernel 6.6 + picom (glx) = no lag amdgpu + kernel 6.6 + picom (xrender) = no lag

The only discernible pattern to me is picom and the kernel.

Update 2: A more thorough testing shows that I was mistaken when I said that restarting picom after waking up from suspend will make the lag go away. This is false. The only way for the issue to go away after waking up from suspend is to restart the entire X server.

anthony-S93 avatar Jan 24 '24 03:01 anthony-S93

@absolutelynothelix wrote:

do you have a reason to have xf86-video-amdgpu installed? these packages tend to create more problems than solve.

Sorry to hijack this issue, but could you elaborate? Should one be using modesetting for AMD cards these days?

haarp avatar Jan 25 '24 12:01 haarp

Update:

After further testing, I discovered that the issue only occurs if my machine is connected to external displays.

anthony-S93 avatar Mar 01 '24 04:03 anthony-S93

Closing this because this isn't a picom issue but an issue with the X server itself. Restarting the X server after waking up from suspend will make the issue go away. I'm also unable to reproduce this issue on a Wayland compositor (sway).

anthony-S93 avatar Mar 03 '24 09:03 anthony-S93