artifacts and poor performance of shadows in the xrender backend

[ProgrammingRainbow]

Running Archlinux and updated my system running Xmonad. The system because increasingly slow as in 1 to 2 second lag. I found the Xorg was running 100% just changing focus or transitioning. Even firefox wasn't resounding properly. Killing picom fixed it. So i started trying different backends and also different versions. It seems Picom-11 used xrender backend and that worked find. But Picom-12 it doesn't work with xrender. Some of the packages had it set to xrender in /etc/xdg/picom.conf and some had it set to glx. The latest is xrender which slowed me down. So for now switching to glx is working. but it seems xrender is bugged and set as the default in archlinux. I am using an AMD 5700u APU if that helps with the latest archlinux packages using the standard mesa open source drivers.

[installgentoo]

For my system with 4500U xrender outright freezes the screen on start and then it starts lagging and glitching

[ProgrammingRainbow]

Yes it freezes for like 1 or 2 seconds. but then every interaction also causes it. so running glxgears and then simply changing focus will cause it to not even render. Glxgears with go form 5000 fps to 50. but it doesn't actually show anything. And Firefox is unusable because each interaction takes a second or more. I thought my SSD was dieing.

[jrobsonchase]

Seeing this on NixOS as well.

Versions: Picom: 12.1 xorg-server: 21.1.13 i3wm: 4.23 kernel: 6.6.53 GPU: AMD Radeon RX 6800 XT (radeonsi, navi21, LLVM 18.1.8, DRM 3.54, 6.6.53) (0x73bf)

Switching backend to glx seems to fix things.

Probably also worth noting that the freezing seems to be CPU-bound - I see the X process' CPU spiking in the time between trying to open a new terminal and seeing it actually render.

[iio7iio7]

I can confirm this on both Artix Linux and FreeBSD running on Intel (using the GPU of the processor). A lot of lagging, especially running stuff in xterm, like looking through directories with Midnight Commander. Also using Vim/Neovim causes lagging, opening a file, nothing happens until after a lag.

This is using Picom 12.1 on i3.

[iio7iio7]

Oh, this problem is on glx as well on my systems.

[yshui]

increasingly slow as in 1 to 2 second lag

do you happen to use wezterm?

[ProgrammingRainbow]

Yeah my CPU hits 100% when interacting with a window or switching. It's not terminal specific. My firefox did it with each interaction. I thought my computer was broken. Also glx doesn't seem to be as good. There is some stuttering too. But no where near the issues with xrender.

[absolutelynothelix]

the xrender backend is slow by itself. it should be gpu-accelerated but it's still quite heavy on the cpu. there are optimization possibilities but this is not in the priority. officially it's set as the default backend in the example configuration file because it was considered to be a safe fallback a long time ago. we were discussing making the glx backend the new default a while ago so maybe it's time to finally do this. i don't see issues with the xrender backend other than this from my short test run.

[ProgrammingRainbow]

Prior to picom 12, I used xrender for years without issue. It was as slow as grease lightning. Its only an issue in picom 12. Its not slow it hangs the sysyem. That's what we mean by slow. It freezes and unfreezes the sysyem over and over making it unusable. Glx almost works as fast but it is slower and also seems to stutter the system.

On Tue, 8 Oct 2024, 14:52 Maxim Solovyov, @.***> wrote:

the xrender backend is slow by itself. it should be gpu-accelerated but it's still quite heavy on the cpu. there are optimization possibilities but this is not in the priority. officially it's set as the default backend in the example configuration file because it was considered to be a safe fallback a long time ago. we were discussing making the glx backend the new default a while ago so maybe it's time to finally do this. i don't see issues with the xrender backend other than this from my short test run.

— Reply to this email directly, view it on GitHub https://github.com/yshui/picom/issues/1349#issuecomment-2399911088, or unsubscribe https://github.com/notifications/unsubscribe-auth/BGC7QTOYMO6KVBBCWE4MM5LZ2PPQPAVCNFSM6AAAAABPOWDGVCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOJZHEYTCMBYHA . You are receiving this because you authored the thread.Message ID: @.***>

[yshui]

@ProgrammingRainbow i feel you didn't answer my question?

[Cyan903]

I am experiencing this exact same problem with xrender set as the backend. I'm using Arch with AwesomWM and Alacritty. I can confirm at least on my end that the CPU spike happens with any window. I've got a Radeon RX 580 as my GPU.

Setting the backend to glx fixed it. I've also used xrender for months at this point without issue until now.

[yshui]

@Cyan903 thanks for the info. do you use blur with xrender? and the CPU spike is from Xorg, right?

[Cyan903]

@Cyan903 thanks for the info. do you use blur with xrender? and the CPU spike is from Xorg, right?

I don't use blur with xrender, but I do use transparency. The CPU spike is from Xorg. Here's my exact config if it helps. Thanks for your reply, let me know if you need any more information.

https://github.com/user-attachments/assets/55c00741-999e-4ae3-8291-e03934018a02

[qouoq]

Seeing the same issue here (with Openbox and a Radeon RX Vega 56 GPU). Also seeing the CPU spikes from Xorg.

Here my picom configuration, if it can help answer whether blur is used.

~/.config/picom.conf

```dosini ################################# # 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 shadow = true; # The blur radius for shadows, in pixels. (defaults to 12) # shadow-radius = 12 # shadow-radius = 7; # The opacity of shadows. (0.0 - 1.0, defaults to 0.75) # shadow-opacity = .75 # The left offset for shadows, in pixels. (defaults to -15) # shadow-offset-x = -15 # shadow-offset-x = -7; # The top offset for shadows, in pixels. (defaults to -15) # shadow-offset-y = -15 # shadow-offset-y = -7; # Avoid drawing shadows on dock/panel windows. This option is deprecated, # you should use the *wintypes* option in your config file instead. # # no-dock-shadow = false # Don't draw shadows on drag-and-drop windows. This option is deprecated, # you should use the *wintypes* option in your config file instead. # # no-dnd-shadow = false # Red color value of shadow (0.0 - 1.0, defaults to 0). # shadow-red = 0 # Green color value of shadow (0.0 - 1.0, defaults to 0). # shadow-green = 0 # Blue color value of shadow (0.0 - 1.0, defaults to 0). # shadow-blue = 0 # Do not paint shadows on shaped windows. Note shaped windows # here means windows setting its shape through X Shape extension. # Those using ARGB background is beyond our control. # Deprecated, use # shadow-exclude = 'bounding_shaped' # or # shadow-exclude = 'bounding_shaped && !rounded_corners' # instead. # # shadow-ignore-shaped = '' # Specify a list of conditions of windows that should have no shadow. # # examples: # shadow-exclude = "n:e:Notification"; # # shadow-exclude = [] shadow-exclude = [ "name = 'Notification'", "class_g = 'Conky'", "class_g ?= 'Notify-osd'", "class_g = 'Cairo-clock'", "_GTK_FRAME_EXTENTS@:c" ]; # Specify a X geometry that describes the region in which shadow should not # be painted in, such as a dock window region. Use # shadow-exclude-reg = "x10+0+0" # for example, if the 10 pixels on the bottom of the screen should not have shadows painted on. # # shadow-exclude-reg = "" # Crop shadow of a window fully on a particular Xinerama screen to the screen. # xinerama-shadow-crop = false ################################# # Fading # ################################# # Fade windows in/out when opening/closing and when opacity changes, # unless no-fading-openclose is used. # fading = false # fading = true # Opacity change between steps while fading in. (0.01 - 1.0, defaults to 0.028) # fade-in-step = 0.028 fade-in-step = 0.03; # Opacity change between steps while fading out. (0.01 - 1.0, defaults to 0.03) # fade-out-step = 0.03 fade-out-step = 0.03; # The time between steps in fade step, in milliseconds. (> 0, defaults to 10) # fade-delta = 10 # Specify a list of conditions of windows that should not be faded. # fade-exclude = [] # Do not fade on window open/close. # no-fading-openclose = false # Do not fade destroyed ARGB windows with WM frame. Workaround of bugs in Openbox, Fluxbox, etc. # no-fading-destroyed-argb = false ################################# # Transparency / Opacity # ################################# # Opacity of inactive windows. (0.1 - 1.0, defaults to 1.0) # inactive-opacity = 1 # inactive-opacity = 0.8; # Opacity of window titlebars and borders. (0.1 - 1.0, disabled by default) # frame-opacity = 1.0 frame-opacity = 0.9; # Default opacity for dropdown menus and popup menus. (0.0 - 1.0, defaults to 1.0) # menu-opacity = 1.0 # Let inactive opacity set by -i override the '_NET_WM_OPACITY' values of windows. # inactive-opacity-override = true inactive-opacity-override = false; # Default opacity for active windows. (0.0 - 1.0, defaults to 1.0) # active-opacity = 1.0 # Dim inactive windows. (0.0 - 1.0, defaults to 0.0) # inactive-dim = 0.0 # Specify a list of conditions of windows that should always be considered focused. # focus-exclude = [] focus-exclude = [ "class_g = 'Cairo-clock'" ]; # Use fixed inactive dim value, instead of adjusting according to window opacity. # inactive-dim-fixed = 1.0 # Specify a list of opacity rules, in the format `PERCENT:PATTERN`, # like `50:name *= "Firefox"`. picom-trans is recommended over this. # Note we don't make any guarantee about possible conflicts with other # programs that set '_NET_WM_WINDOW_OPACITY' on frame or client windows. # example: # opacity-rule = [ "80:class_g = 'URxvt'" ]; # # opacity-rule = [] ################################# # Background-Blurring # ################################# # Parameters for background blurring, see the *BLUR* section for more information. # blur-method = # blur-size = 12 # # blur-deviation = false # Blur background of semi-transparent / ARGB windows. # Bad in performance, with driver-dependent behavior. # The name of the switch may change without prior notifications. # # blur-background = false # Blur background of windows when the window frame is not opaque. # Implies: # blur-background # Bad in performance, with driver-dependent behavior. The name may change. # # blur-background-frame = false # Use fixed blur strength rather than adjusting according to window opacity. # blur-background-fixed = false # Specify the blur convolution kernel, with the following format: # example: # blur-kern = "5,5,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1"; # # blur-kern = '' blur-kern = "3x3box"; # Exclude conditions for background blur. # blur-background-exclude = [] blur-background-exclude = [ "window_type = 'dock'", "window_type = 'desktop'", "_GTK_FRAME_EXTENTS@:c" ]; ################################# # General Settings # ################################# # Daemonize process. Fork to background after initialization. Causes issues with certain (badly-written) drivers. # daemon = false # Specify the backend to use: `xrender`, `glx`, or `xr_glx_hybrid`. # `xrender` is the default one. # # backend = 'glx' backend = "xrender"; # Enable/disable VSync. # vsync = false vsync = true # Enable remote control via D-Bus. See the *D-BUS API* section below for more details. # dbus = false # Try to detect WM windows (a non-override-redirect window with no # child that has 'WM_STATE') and mark them as active. # # mark-wmwin-focused = false mark-wmwin-focused = true; # Mark override-redirect windows that doesn't have a child window with 'WM_STATE' focused. # mark-ovredir-focused = false mark-ovredir-focused = true; # Try to detect windows with rounded corners and don't consider them # shaped windows. The accuracy is not very high, unfortunately. # # detect-rounded-corners = false detect-rounded-corners = true; # Detect '_NET_WM_OPACITY' on client windows, useful for window managers # not passing '_NET_WM_OPACITY' of client windows to frame windows. # # detect-client-opacity = false detect-client-opacity = true; # Specify refresh rate of the screen. If not specified or 0, picom will # try detecting this with X RandR extension. # # refresh-rate = 60 refresh-rate = 0 # Limit picom to repaint at most once every 1 / 'refresh_rate' second to # boost performance. This should not be used with # vsync drm/opengl/opengl-oml # as they essentially does sw-opti's job already, # unless you wish to specify a lower refresh rate than the actual value. # # sw-opti = # Use EWMH '_NET_ACTIVE_WINDOW' to determine currently focused window, # rather than listening to 'FocusIn'/'FocusOut' event. Might have more accuracy, # provided that the WM supports it. # # use-ewmh-active-win = false # Unredirect all windows if a full-screen opaque window is detected, # to maximize performance for full-screen windows. Known to cause flickering # when redirecting/unredirecting windows. # # unredir-if-possible = false # Delay before unredirecting the window, in milliseconds. Defaults to 0. # unredir-if-possible-delay = 0 # Conditions of windows that shouldn't be considered full-screen for unredirecting screen. # unredir-if-possible-exclude = [] # Use 'WM_TRANSIENT_FOR' to group windows, and consider windows # in the same group focused at the same time. # # detect-transient = false detect-transient = true # Use 'WM_CLIENT_LEADER' to group windows, and consider windows in the same # group focused at the same time. 'WM_TRANSIENT_FOR' has higher priority if # detect-transient is enabled, too. # # detect-client-leader = false detect-client-leader = true # Resize damaged region by a specific number of pixels. # A positive value enlarges it while a negative one shrinks it. # If the value is positive, those additional pixels will not be actually painted # to screen, only used in blur calculation, and such. (Due to technical limitations, # with use-damage, those pixels will still be incorrectly painted to screen.) # Primarily used to fix the line corruption issues of blur, # in which case you should use the blur radius value here # (e.g. with a 3x3 kernel, you should use `--resize-damage 1`, # with a 5x5 one you use `--resize-damage 2`, and so on). # May or may not work with *--glx-no-stencil*. Shrinking doesn't function correctly. # # resize-damage = 1 # Specify a list of conditions of windows that should be painted with inverted color. # Resource-hogging, and is not well tested. # # invert-color-include = [] # GLX backend: Avoid using stencil buffer, useful if you don't have a stencil buffer. # Might cause incorrect opacity when rendering transparent content (but never # practically happened) and may not work with blur-background. # My tests show a 15% performance boost. Recommended. # # glx-no-stencil = false # GLX backend: Avoid rebinding pixmap on window damage. # Probably could improve performance on rapid window content changes, # but is known to break things on some drivers (LLVMpipe, xf86-video-intel, etc.). # Recommended if it works. # # glx-no-rebind-pixmap = false # Disable the use of damage information. # This cause the whole screen to be redrawn everytime, instead of the part of the screen # has actually changed. Potentially degrades the performance, but might fix some artifacts. # The opposing option is use-damage # # no-use-damage = false use-damage = true # Use X Sync fence to sync clients' draw calls, to make sure all draw # calls are finished before picom starts drawing. Needed on nvidia-drivers # with GLX backend for some users. # # xrender-sync-fence = false # GLX backend: Use specified GLSL fragment shader for rendering window contents. # See `compton-default-fshader-win.glsl` and `compton-fake-transparency-fshader-win.glsl` # in the source tree for examples. # # glx-fshader-win = '' # Force all windows to be painted with blending. Useful if you # have a glx-fshader-win that could turn opaque pixels transparent. # # force-win-blend = false # Do not use EWMH to detect fullscreen windows. # Reverts to checking if a window is fullscreen based only on its size and coordinates. # # no-ewmh-fullscreen = false # Dimming bright windows so their brightness doesn't exceed this set value. # Brightness of a window is estimated by averaging all pixels in the window, # so this could comes with a performance hit. # Setting this to 1.0 disables this behaviour. Requires --use-damage to be disabled. (default: 1.0) # # max-brightness = 1.0 # Make transparent windows clip other windows like non-transparent windows do, # instead of blending on top of them. # # transparent-clipping = false # Set the log level. Possible values are: # "trace", "debug", "info", "warn", "error" # in increasing level of importance. Case doesn't matter. # If using the "TRACE" log level, it's better to log into a file # using *--log-file*, since it can generate a huge stream of logs. # # log-level = "debug" log-level = "warn"; # Set the log file. # If *--log-file* is never specified, logs will be written to stderr. # Otherwise, logs will to written to the given file, though some of the early # logs might still be written to the stderr. # When setting this option from the config file, it is recommended to use an absolute path. # # log-file = '/path/to/your/log/file' # Show all X errors (for debugging) # show-all-xerrors = false # Write process ID to a file. # write-pid-path = '/path/to/your/log/file' # Window type settings # # 'WINDOW_TYPE' is one of the 15 window types defined in EWMH standard: # "unknown", "desktop", "dock", "toolbar", "menu", "utility", # "splash", "dialog", "normal", "dropdown_menu", "popup_menu", # "tooltip", "notification", "combo", and "dnd". # # Following per window-type options are available: :: # # fade, shadow::: # Controls window-type-specific shadow and fade settings. # # opacity::: # Controls default opacity of the window type. # # focus::: # Controls whether the window of this type is to be always considered focused. # (By default, all window types except "normal" and "dialog" has this on.) # # full-shadow::: # Controls whether shadow is drawn under the parts of the window that you # normally won't be able to see. Useful when the window has parts of it # transparent, and you want shadows in those areas. # # redir-ignore::: # Controls whether this type of windows should cause screen to become # redirected again after been unredirected. If you have unredir-if-possible # set, and doesn't want certain window to cause unnecessary screen redirection, # you can set this to `true`. # wintypes: { tooltip = { fade = true; shadow = true; opacity = 0.9; focus = true; full-shadow = false; }; dock = { shadow = false; } dnd = { shadow = false; } popup_menu = { opacity = 0.9; } dropdown_menu = { opacity = 0.9; } }; ```

Switching to the glx backend seems like a good solution.

[Tigermouthbear]

Having this problem too, switching backend to glx fixed it for me.

Picom: v12.1 (/startdir/picom revision c321da4) xorg-server: 21.1.13-1 wm: dwm (w/ various patches)

OS: Arch Linux Kernel: 6.11.2-arch1-1 CPU: AMD Ryzen 9 6900HS Creator Edition IGPU: AMD ATI Radeon 680M

Config: https://github.com/Tigermouthbear/dwm/blob/flexipatch/picom.conf

[yshui]

can you try disabling shadow as well?

[ProgrammingRainbow]

I'm not using shadows.

On Thu, 10 Oct 2024, 08:50 Yuxuan Shui, @.***> wrote:

can you try disabling shadow as well?

— Reply to this email directly, view it on GitHub https://github.com/yshui/picom/issues/1349#issuecomment-2404338184, or unsubscribe https://github.com/notifications/unsubscribe-auth/BGC7QTMSUXLQU5Q7ECNZWJTZ2YWWFAVCNFSM6AAAAABPOWDGVCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBUGMZTQMJYGQ . You are receiving this because you were mentioned.Message ID: @.***>

[yshui]

hmm, which xf86-video driver do you use? is it modesetting or amdgpu?

there really isn't enough info to work off of. if you can, try profiling the X server and see what's using so much CPU in there.

[qouoq]

For my part I'm using xf86-video-amdgpu as the driver.

Deactivating shadows makes the lag disappear.

Attempting to profile CPU usage with Sysprof indicates that most time is spent by Xorg in libpixman-1.so. I don't know how to get or view the debug symbols though.

[yshui]

hmm, conflicting information here. is this actually related to shadows or not? :thinking:

[ProgrammingRainbow]

I'm sorry i did not understand before about the shadowing. I'm not using any thing that looks like shadows but yes it is enabled in the config. I went back to picom 11 with shadow enabled and xrender is fine. in picom 12 all versions shadow is still on but xrender causes the issue. With shadow off and xrender it is fast again yes. I am using amdgpu no special settings just default out of the box archlinux.

try profiling the X server and see what's using so much CPU in there.

Certainly. Uh, but how? In htop it was xorg that was taking 100% cpu. There is actually14 xorg running but just 1 spikes to 100% and the whole system freezes.

[yshui]

perf record -p <Xorg's pid>
perf report

you might need sudo. more resources on how to perf: https://www.brendangregg.com/perf.html, https://perf.wiki.kernel.org/index.php/Tutorial

[ProgrammingRainbow]

A whole lot of this.

14.57% Xorg libpixman-1.so.0.43.4 [.] 0x0000000000012328 ◆ 1.97% Xorg libpixman-1.so.0.43.4 [.] 0x0000000000012325 ▒ 1.31% Xorg libpixman-1.so.0.43.4 [.] 0x0000000000019c69 ▒ 1.30% Xorg libpixman-1.so.0.43.4 [.] 0x0000000000006e42 ▒ 1.28% Xorg libpixman-1.so.0.43.4 [.] 0x0000000000019c6b ▒ 1.26% Xorg libpixman-1.so.0.43.4 [.] 0x0000000000012367 ▒ 1.20% Xorg libpixman-1.so.0.43.4 [.] 0x0000000000019c85 ▒ 1.16% Xorg libpixman-1.so.0.43.4 [.] 0x0000000000012361 ▒ 1.13% Xorg libpixman-1.so.0.43.4 [.] 0x0000000000012365 ▒ 1.09% Xorg libpixman-1.so.0.43.4 [.] 0x0000000000006e53 ▒ 0.99% Xorg libpixman-1.so.0.43.4 [.] 0x0000000000019cab ▒ 0.98% Xorg libpixman-1.so.0.43.4 [.] 0x00000000000122e6 ▒ 0.96% Xorg libpixman-1.so.0.43.4 [.] 0x0000000000019c89 ▒ 0.96% Xorg libpixman-1.so.0.43.4 [.] 0x00000000000122f3 ▒ 0.94% Xorg libpixman-1.so.0.43.4 [.] 0x0000000000019cb4 ▒ 0.94% Xorg libpixman-1.so.0.43.4 [.] 0x000000000001230a ▒ 0.94% Xorg libpixman-1.so.0.43.4 [.] 0x0000000000019cb9 ▒ 0.93% Xorg libpixman-1.so.0.43.4 [.] 0x0000000000019c97 ▒ 0.92% Xorg libpixman-1.so.0.43.4 [.] 0x00000000000122e0 ▒ 0.91% Xorg libpixman-1.so.0.43.4 [.] 0x00000000000122e4 ▒ 0.91% Xorg libpixman-1.so.0.43.4 [.] 0x00000000000122e9 ▒ 0.90% Xorg libpixman-1.so.0.43.4 [.] 0x0000000000012302 ▒ 0.90% Xorg libpixman-1.so.0.43.4 [.] 0x00000000000122f7 ▒ 0.90% Xorg libpixman-1.so.0.43.4 [.] 0x0000000000019c9b ▒ 0.89% Xorg libpixman-1.so.0.43.4 [.] 0x0000000000019cbc ▒ 0.86% Xorg libpixman-1.so.0.43.4 [.] 0x00000000000122f0 ▒ 0.83% Xorg libpixman-1.so.0.43.4 [.] 0x0000000000012323 ▒ 0.83% Xorg libpixman-1.so.0.43.4 [.] 0x0000000000012320 ▒ 0.79% Xorg libpixman-1.so.0.43.4 [.] 0x0000000000019c7a

[yshui]

so same story as https://github.com/yshui/picom/issues/1349#issuecomment-2405547061 but i do need to see the function names though... maybe you need to install debug symbols for pixman?

[yshui]

i also wonder if the modesetting driver will help. if you can, try just remove xf86-video-amdgpu?

[ProgrammingRainbow]

Do i need to recompile pixman? I'm just using the arch package. is there an aur that debuging or a switch i can use?

[yshui]

it's a bit complicated. you are using X & pixman from archlinux repo, right? in that case, upload your perf.data, i should be able to look at it.

[ProgrammingRainbow]

Does this help?

47.58% Xorg libpixman-1.so.0.43.4 [.] bits_image_fetch_general 39.17% Xorg libpixman-1.so.0.43.4 [.] fetch_pixel_general_32 6.42% Xorg libpixman-1.so.0.43.4 [.] fetch_pixel_a8.lto_priv.0 0.32% Xorg libpixman-1.so.0.43.4 [.] store_scanline_a8.lto_priv.0 0.19% Xorg libpixman-1.so.0.43.4 [.] fetch_scanline_a8.lto_priv.0 0.12% Xorg libpixman-1.so.0.43.4 [.] sse2_combine_over_u.lto_priv.0 0.08% Xorg:cs0 [kernel.kallsyms] [k] amdgpu_cs_ioctl 0.08% Xorg:cs0 [kernel.kallsyms] [k] amdgpu_sync_resv 0.06% Xorg [kernel.kallsyms] [k] srso_return_thunk 0.05% Xorg:cs0 [kernel.kallsyms] [k] srso_return_thunk 0.05% Xorg [kernel.kallsyms] [k] srso_safe_ret 0.05% Xorg:cs0 [kernel.kallsyms] [k] memset_orig 0.05% Xorg [kernel.kallsyms] [k] unix_stream_sendmsg 0.04% Xorg [kernel.kallsyms] [k] _regmap_read 0.04% Xorg [kernel.kallsyms] [k] memset_orig 0.04% Xorg:cs0 [kernel.kallsyms] [k] sort_r 0.04% Xorg [kernel.kallsyms] [k] select_task_rq_fair 0.04% Xorg:cs0 [kernel.kallsyms] [k] srso_safe_ret 0.03% Xorg [kernel.kallsyms] [k] try_to_wake_up 0.03% Xorg [kernel.kallsyms] [k] syscall_exit_to_user_mode 0.03% Xorg [kernel.kallsyms] [k] x86_indirect_thunk_rax 0.03% Xorg:cs0 [kernel.kallsyms] [k] amdgpu_vm_bo_update 0.03% Xorg libc.so.6 [.] 0x000000000016d089 0.03% Xorg:cs0 [kernel.kallsyms] [k] amdgpu_cs_parser_bos.isra.0 0.03% Xorg [kernel.kallsyms] [k] read_tsc 0.02% Xorg:cs0 [kernel.kallsyms] [k] drm_exec_lock_obj 0.02% Xorg:cs0 [kernel.kallsyms] [k] __check_object_size 0.02% Xorg:cs0 [kernel.kallsyms] [k] amdgpu_bo_list_create 0.02% Xorg libc.so.6 [.] 0x000000000016d093

[ProgrammingRainbow]

there is a debug companion debug for all packages i found for archlinux.

[ProgrammingRainbow]

This is with the xf86-video-amdgpu removed and modesetting set. It doesn't freeze the system. But this is me switching windows as fast as possible with a key binding. So although it shows CPU usage it was still acting fluidly.

48.18% Xorg [kernel.kallsyms] [k] copy_page 5.48% Xorg [kernel.kallsyms] [k] shmem_get_folio_gfp 5.28% Xorg [kernel.kallsyms] [k] filemap_get_entry 3.25% Xorg [kernel.kallsyms] [k] shmem_read_mapping_page_gfp 2.60% Xorg [kernel.kallsyms] [k] ttm_tt_swapout 2.13% Xorg [kernel.kallsyms] [k] folio_mark_accessed 1.78% Xorg [kernel.kallsyms] [k] clear_page_rep 1.59% Xorg [kernel.kallsyms] [k] srso_safe_ret 1.55% Xorg [kernel.kallsyms] [k] srso_return_thunk 1.33% Xorg [kernel.kallsyms] [k] noop_dirty_folio 1.11% Xorg [kernel.kallsyms] [k] x86_indirect_thunk_rax 0.89% Xorg [kernel.kallsyms] [k] rcu_read_lock 0.81% Xorg [kernel.kallsyms] [k] ttm_bo_swapout 0.80% Xorg [kernel.kallsyms] [k] mark_page_accessed 0.68% Xorg [kernel.kallsyms] [k] rep_movs_alternative 0.50% Xorg [kernel.kallsyms] [k] folio_mapping 0.44% Xorg [kernel.kallsyms] [k] get_page_from_freelist 0.40% Xorg [kernel.kallsyms] [k] rmqueue_pcplist 0.37% Xorg [kernel.kallsyms] [k] read_hpet 0.28% Xorg [kernel.kallsyms] [k] shmem_add_to_page_cache 0.25% Xorg [kernel.kallsyms] [k] __mod_memcg_lruvec_state 0.25% Xorg [kernel.kallsyms] [k] lruvec_stat_mod_folio 0.23% Xorg [kernel.kallsyms] [k] shmem_alloc_and_add_folio

[yshui]

@ProgrammingRainbow so it works normally with modesetting? i think we can pin the blame on xf86-video-amdgpu and say "not our problem" then :smiling_imp:

[ProgrammingRainbow]

But why is this issue only showing up with picom? In kde there is no issue with amdgpu. It seems specific to picom. Is there a specific setting in KDE i could check for the equivalent shadow? Because in the default KDE with all it's normal drop shadows and transparency it has no issue. I had to switch to KDE before i figured out picom was an issue. Also why is it specific to picom 12? I think to say it's xf86-video-amdgpu the issue is not accurate. To say it's "picom 12" + amdgpu would be correct. And then again the question as to why picom 12 what changed in picom? The amdgpu also has not been changed for over a year and a half. So it seem extremely unlikely that a bug suddenly showed up in a driver that has been the same since the beginning of 2023.

[yshui]

it's just how picom does things triggered bad behavior in amdgpu. kde/kwin doesn't even have a xrender backend anymore, so if you are comparing with them, you should be comparing them against picom's glx backend.

the fact everything works fine with modesetting proves picom is not doing anything wrong. most likely amdgpu just implemented certain operations used by picom v12 very very inefficiently. nowadays modesetting is the recommended driver anyways.

i will pin this issue so people with the same problem know what to do.

[ProgrammingRainbow]

Again it seems the only isolated variable here is picom 12. It seems very strange to pass the blame when causing the bug requires 1 specific thing, is required picom 12. not other version of picom. How did amdgpu know to make it work with picom 11 and not 12. It reads a like attempting to pass the issue when the bug is specific to a specific version of a specific piece of software. Would the xf86-video-amdgpu not just state to obvious that nope the bug is not on there end?

[yshui]

Again it seems the only isolated variable here is picom 12.

no? you forgot xf86-video-amdgpu vs. modesetting.

my reasoning it very clearly explained in my previous comment, and i think you are missing some of the points there. i don't have anything to add in that regard.

[yshui]

For people reading this issue, the current recommendation is this:

• consider using the glx backend, but if you have a good reason to use the xrender backend, then
• remove xf86-video-amdgpu and use the modesetting driver.

[absolutelynothelix]

@ProgrammingRainbow, practice shows that all the xf86-video drivers are evil and we advise to use the modesetting one. if we spent time figuring out all the bugs caused by xf86-video drivers picom would stuck at v10.

[yshui]

ok, i think this is it.

turns out i am both right and wrong. i was right that xf86-video-amdgpu does certain operations picom needs (specifically convolution filters) rather inefficiently. i was wrong in the sense that, modesetting isn't any better either. we just had a workaround for it in place:

https://github.com/yshui/picom/blob/8370ebf00dbf67fe6b15bf592a3a28db4f5c028a/src/backend/xrender/xrender.c#L959-L962

[ProgrammingRainbow]

I just saw all these replies today. But my thought is as i originally said the issue was specific to picom 12 and there was an attempt to shift the blame. I'm not a driver developer but when taking the scientific approach you should remove any variables possible and picom specifically could not be removed as a variable. The issue required a specific version of picom not a specific version of xf86-video-amdgpu. If that helps in the future. Also it was stated above that although glx seemed to mitigate most of the issue there was or is still micro freezing. Something i have never seen in the past.

[absolutelynothelix]

tl;dr use the modesetting ddx driver instead of the intel's one.

we have two paths of generating and rendering shadows in the xrender backend: 1) performed by the ddx driver using the x render extension's convolution picture filter that's supposed to be accelerated thus supposed to be fast - let's call it the "fast" path; 2) performed by us thus supposed to be slow - let's call it the "slow" path.

we used to assume that all the vendors' ddx drivers have a proper accelerated convolution filter but this assumption turned to be wrong. we started to assume that the intel's ddx driver has it but this assumption turned to be wrong as well - it indeed has an accelerated convoltion filter but it's quite limited and isn't enough for picom's needs. in the end it turned that the "fast" path is actually slow and the "slow" path is actually fast.

the "fast" path also has a rendering issue that may be a bug on our side.

for now the issues mentioned above affect only the intel's ddx driver. it's advised to use the modesetting ddx driver instead of the intel's one simply because of the latter being abandoned and instead of all the vendors' ddx drivers in general because they're all cursed ahh.

[absolutelynothelix]

an update on artifacts: there are indeed artifacts but they're only present when the intel's ddx driver is used so the situation for it is: 1) the convolution filter is accelerated for 0 < shadow radius <= 15; 2) the convolution filter generates artifacts for 1 < shadow radius <= 15; 3) the convolution filter isn't accelerated for shadow radius > 15.

so the only usable shadow radius for it is 1 😂

[absolutelynothelix]

i pushed a (hopefully temporary) workaround for all the issues with shadows in the xrender backend to the next branch. now they should work well no matter what ddx driver is used.

leaving this open until we decide what to do with everything we learned about ddx drivers.

[gh0stzk]

i pushed a (hopefully temporary) workaround for all the issues with shadows in the xrender backend to the next branch. now they should work well no matter what ddx driver is used.

leaving this open until we decide what to do with everything we learned about ddx drivers.

I just test your last commit, yes artifacts and poor performance are gone (In my case). I tested with big shadow radius like 20 and with the default one.

Update: There is still a little bad performance with big shadow radius like 20 for example. The defaults works fine or at least is not notorious.