search

swaywm / sway

i3-compatible Wayland compositor
https://swaywm.org
MIT License
14.64k stars 1.11k forks source link

High CPU usage when moving mouse cursor #3751

Open GSF1200S opened 5 years ago

GSF1200S commented 5 years ago

sway version 1.0-rc1-98-gd3d79565 (Feb 22 2019, branch 'master')

I am running an up-to-date Arch install with the latest pull of wlroots and sway from git, and I am using the nouveau drivers for an Nvidia card. CPU is an i7 920 running at 3.3ghz, 12GB RAM, multi-threading off.

When typing or performing any function for Sway, CPU usage is about what I would expect. If I move the mouse cursor around however, CPU usage jumps from ~1-2% to 20-30% on all 4 cores. Sometimes cores will spike up to 60% or so, but usually it stabilizes around 20%.

I am unsure if this is a Nouveau problem, a wlroots problem, or a sway problem. I experience no jittery behavior or lagging, so this is far from a deal-breaker for me- I figure it should be reported though. For awhile I had issues with a disappearing cursor and used software cursor support (via an environment variable), but that seems to have been resolved as hardware cursor support has no issues with a disappearing cursor. FWIW though, CPU usage is about ~50% for me if I have software cursor set. This isn't really a crash so I don't have any debug logs or anything. If you require any additional information, I would be happy to provide it.

RedSoxFan commented 5 years ago

Maybe related to https://github.com/swaywm/wlroots/pull/1537

emersion commented 5 years ago

Maybe related to swaywm/wlroots#1537

I don't think so, since moving the cursor shouldn't update its image.

Maybe we shouldn't send an atomic test commit each time the cursor moves (but instead do it once per pageflip).

Can you upload logs? (Maybe this is a legacy interface issue)

RedSoxFan commented 5 years ago

I don't think so, since moving the cursor shouldn't update its image.

It could be depending on if it is cross surface boundaries or the client is changing it.

ascent12 commented 5 years ago

Nouveau isn't atomic by default, so it's more likely he's using legacy. Frequent uses of glFinish certainly could mean higher CPU usage.

emersion commented 5 years ago

Maybe we shouldn't drmModeMoveCursor at each input event?

Frequent uses of glFinish certainly could mean higher CPU usage.

This also happens only if the cursor image changes. @GSF1200S, does the issue happen if you move the cursor without making it change its image?

GSF1200S commented 5 years ago

sway.log Sorry for the delay- I was at work.

This issue occurs with all usage of the mouse. If I move the mouse around on the root of a workspace, high CPU usage occurs. If I move the mouse around over a window (say termite) where the cursor doesn't change, I get the same result. If I move it around where the cursor does change, the result is the same (and CPU usage doesn't seem any higher than with no cursor change).

Im unsure exactly what video cards use a legacy interface, but I reason its likely my ancient geforce 9800GTX video card does. Its also worth noting (as you'll see in the debug log) I have dual screens, and that I have both screens driven off that one video card. I updated from git before taking this log just so everyone would know where I was at. If you need anything else, please let me know.

simon-auch commented 5 years ago

I just wanted to comment, that I am still experiencing this problem on: Sway: 1.1.1-3 Linux: 5.1.15.arch1-1 mesa: 19.1.1-1 cpu: Intel Skylake i5 6600k gpu: Intel HD Graphics 530 wlroots: 0.6.0-1

When moving the mouse cursor over a window, cpu goes to around 20-30%. As for what causes this I have no real idea, but two things i noticed: 1) cpu usage is always accounted to the process of the window, not sway itself (according to htop) 2) the window seems to redraw everything (similar to resizing the window). I especially noticed this in alacritty with the option debug.render_timer: true.

emersion commented 5 years ago

@raidwas This is not a sway issue.

simon-auch commented 5 years ago

@emersion So where should I report the issue?

Maybe we shouldn't drmModeMoveCursor at each input event?

Frequent uses of glFinish certainly could mean higher CPU usage.

This also happens only if the cursor image changes. @GSF1200S, does the issue happen if you move the cursor without making it change its image?

Since it also happens without the cursor changing its image, I thought it would not be related to swaywm/wlroots#1537

emersion commented 5 years ago

If alacritty is using CPU, this is an alacritty issue

simon-auch commented 5 years ago

Since it only appears to happen when using sway (wayland?) and not when using xfce4 (xorg?) I thought this would be more of a sway issue than a alacritty issue (like sending a signal to redraw stuff, even if there is nothing to do).

ascent12 commented 5 years ago

The way wayland works, we will send a event suggesting a time to redraw if and only if they ask for it. It's common for applications to unconditionally ask for this event, and use it to throttle/vsync their application, which is especially true for OpenGL applications.

If alacritty is not properly reusing their buffers or is otherwise being wasteful with their rendering, that's their issue. There is nothing we can do about it.

FedericoCeratto commented 4 years ago

I'm seeing a similar behavior on Sway 1.0~rc3 and 1.2, Wayland 1.20.6-1, Kernel 5.2.0-3-amd64. Moving a mouse around on an application makes the application use 10 to 40% of CPU time constantly. It happens on various applications.

mgyorke commented 4 years ago

I'm having the same issue, high cpu usage when moving the mouse.

I tested on two of my computers after a reboot without opening anything else:

Tested with several mouses (mice?) that I had laying around, a few Logitech M100, M185, G603, Microsoft Sculpt Ergonomic something (the one shaped like a ball), Microsoft Wireless 1000 and an old Corsair gaming mouse (I can't make out the model as the label is worn out)

I just move the mouse in a circle, only Alacritty is opened and running htop. The CPU usage stays around ~40% on the laptop and ~15% on the workstation.

I could only reproduce the issue on the device with a high polling rate, the Corsair and Logitech G603. On the G603 I have a switch that changes the pooling frequency on the fly and I can clearly see the CPU usage dropping on LOW setting.

Even so, with the other mouses there CPU usage still raises when moving the cursor around. It's just that it manages to stay bellow 10% (on the laptop).

Also, worth clarifying that I'm talking of the sway's process cpu usage.

Please let me know if I can help with further testing.

emersion commented 4 years ago

perf records would help figuring out what's using CPU.

jsravn commented 4 years ago

Just to confirm I am also seeing this issue when trying to run Sway 1.4 off of integrated Intel graphics, in a machine with a dedicated GPU (with nouveau driver). Sway is stuck at a constant 20% CPU. When moving the mouse on a Wayland window or the sway background, CPU goes up to about 30%. When moving the mouse over an XWayland window, it jumps up to over 100% CPU. I will try to dig further into what might be causing it.

jsravn commented 4 years ago

Funnily enough, installing nvidia drivers fixes the problem. Maybe nouveau is doing some sort of pass through to the onboard graphics? If so then explicitly setting WLR_DRM_DEVICES=/dev/dri/card1 may also fix things.

apiraino commented 3 years ago

I'd like to add my data point to this bug (and thus subscribe it).

Fresh install of Debian bullseye (5.9.0-4-amd64 #1 SMP Debian 5.9.11-1 2020-11-27), Sway 1.5, default config, xwayland disabled.

Hardware: AMD Ryzen 1700, 16 gb RAM, GeForce GTX 1060 3GB, using Nouveau (debian pkg libdrm-nouveau2 v2.4.103-2)

Symptoms:

My gut feeling is that all this is connected to some issue with Sway+Nouveau but I have no idea where to go from here.

EDIT: ugh ... I solved my issue, leaving here the solution in case it helps. The default Debian installation does not install proprietary firmwares. By looking at the dmesg kernel error messages I've identified a missing scrubber.bin firmware and installed it with apt install firmware-misc-nonfree .