https://bugs.kde.org/show_bug.cgi?id=440386
--- Comment #5 from Fabian Vogt <fab...@ritter-vogt.de> --- I did some more comparisions with weston. perf shows that while weston runs into the "fs_variant_whole" path in llvmpipe, kwin_wayland almost exclusively uses the slower "fs_variant_partial" functions. With LP_DEBUG=counters, it's visible that weston triggers this because it renders mostly opaque triangles, while kwin doesn't have any of them. With apitrace, it's visible that Weston does rendering with GL_BLEND disabled, but kwin_wayland has it enabled. While the surface(s) used by firefox are all RGBA, it calls "set_opaque_region" to make them totally opaque: [4161028,247] -> xdg_surface@45.set_window_geometry(0, 0, 1920, 982) [4161028,579] -> wl_compositor@4.create_region(new id wl_region@54) [4161028,740] -> wl_reg...@54.add(0, 0, 1920, 982) [4161029,064] -> wl_surface@41.set_opaque_region(wl_region@54) [4161029,197] -> wl_region@54.destroy() KWin seems to ignore this. With disabled blending, kwin uses "fs_variant_whole" as well and CPU usage goes down ~10%. What I also noticed is that firefox uses two surfaces for rendering. The main surface is completely empty (all transparent) and only its subsurface has content. While weston draws a single quad, kwin renders both. This doesn't seem to make a big difference, it's probably discarded early on. My current theory about the huge difference between DRM and other platforms is that access to the mapped framebuffer is just slow (for blending that hits twice), and on top of that it's mapped and unmapped for each frame, which causes page faults. -- You are receiving this mail because: You are watching all bug changes.
