https://bugs.kde.org/show_bug.cgi?id=440386
--- Comment #2 from Fabian Vogt <fab...@ritter-vogt.de> --- > FWICT, the high CPU utilization is mostly from having a higher target frame > rate than is actually displayed, which makes kwin_wayland fully CPU bound. I somehow totally forgot that this was with the Show FPS effect enabled, which causes kwin to render as fast as possible, even if no client actually requests a repaint. By counting how often RenderLoop::endFrame is called per second instead (not being that familiar with kwin, I'm not entirely sure that's the right place either), the real repaints per second are visible. With a video in a single firefox window this averages at ~55, so this isn't actually the cause in this specific scenario. With multiple windows or just moving the cursor it does reach ~172 though. After eliminating the hot spot in AbstractEglTexture::createTextureSubImage (apparently FF and Xwayland both use shm), perf shows that most of the time is spent in llvmpipe. What I do not understand so far is why this is not the case in an X11 session (~24% CPU), not even inside kwin_wayland --x11-display $DISPLAY (kwin_x11 25%, kwin_wayland 9.6%). It only happens when using kwin_wayland --drm. Maybe swrast has some issues when the render target is DRM? -- You are receiving this mail because: You are watching all bug changes.
