User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:97.0) Gecko/20100101 Firefox/97.0

Steps to reproduce:

In a Sway or Plasma Wayland session, set gfx.webrender.compositor & gfx.webrender.compositor.force-enabled = true. With VAAPI hardware decoding and native Wayland backend enabled, play 720p 60fps VP9 YT video on slow Gemini Lake SoC:
https://www.youtube.com/watch?v=aqz-KE-bpKQ

Actual results:

GPU load increases by 20% and SoC power consumption by ~0.5-1W accordingly vs. WR Compositor off.

Expected results:

WR Compositor should help to reduce GPU load and power consumption, not increase it.

Tested with FF 97.b3 on latest Plasma 5.23.90 beta and latest sway & wlroots git-master build. Also latest mesa git-master build and latest Wayland Protocols package from Arch repository (that already includes dma-buf-feedback support). Linux 5.16.

For the record: assuming this was measured for fullscreen video play we would expect:

1. one fullscreen copy less if scanout is used either for both backends or none
2. equal amount of copies if scanout is used for the default EGL backend but not for the compositor one (likely to be the case until bug 1743631 is implemented)

There appear to be some kernel patches floating around that would allow intel_gpu_top to show the GPU usage on a per client base. Once they land it will be much easier to check where the overhead actually is. My assumption would be that the overhead happens in the Wayland compositors, but there are also a few other possibilities.

Should have mentioned this:
I didn't test in fullscreen (more hassle with logging data instead of just reading them ad hoc), but in half-screen tiled windows (Firefox + terminal emulator) without windows overlapping. I suppose also windowed power consumption ideally should never increase just by enabling WR Compositor. :)

I could also test another case with power consumption during scrolling without video playback in windowed mode, I suspect the outcome would be similar (as there is more scrolling stutter with WR Compositor).

(In reply to walmartguy from comment #2)

I could also test another case with power consumption during scrolling without video playback in windowed mode, I suspect the outcome would be similar (as there is more scrolling stutter with WR Compositor).

In theory scrolling should have much lower GPU utilization, a bit more than half of what the default backend does.

I could also reproduce it with keyboard scrolling: I open this site, scroll down to the bottom once to cache things and then do keyboard scrolling by keeping up and down arrows pushed until reaching top or bottom of the site: https://bugzilla.mozilla.org/show_bug.cgi?id=1750457

With WR compositor on, GPU power consumption is ~0.5W higher and there is more stutter. For this test I've again used half-screen window tiles on KWin/Plasma.

I'll give Gnome a try tomorrow. Unfortunately I'll be only able to use latest stable packages from Arch repo for this and not latest beta or alpha (usually late in gnome-unstable repo on Arch, same may go for new major stable releases).

Clipboard cheated on me, was supposed to be that link: https://blog.mozilla.org/en/mozilla/firefox-relay-and-premium-service/

I'll give Gnome a try tomorrow. Unfortunately I'll be only able to use latest stable packages from Arch repo.

That would be great. The relevant compositor opmitizations should all be in Gnome 41.

This behavior also applies on Gnome Wayland. Less distinct though, but it definitely reports higher GPU usage and consumes more power with WR compositor on than with WR compositor off with both video and scrolling (at least +0.2W GPU and total SoC something like +0.3W).

(In reply to walmartguy from comment #7)

This behavior also applies on Gnome Wayland. Less distinct though, but it definitely reports higher GPU usage and consumes more power with WR compositor on than with WR compositor off with both video and scrolling (at least +0.2W GPU and total SoC something like +0.3W).

Thanks, that's something I really did not expect. Based on paint times measured in Firefox (which as expected are massively lower, giving that many operations are completely offloaded) I'm pretty this is caused by missing optimizations in the Wayland compositor. As of Mutter/Gnome I'm quite puzzled why that is though.

One thing that came to my mind is that the mipmapping code may not be well adapted to viewports etc. So maybe Mutter is constantly regenerating mipmaps of many sizes instead of just blitting. Will check that's the case.

I could imagine that this is really hard to tell with almost any other GPU, as Gemini Lake GPU is both extremely slow and extremely inefficient at the same time. In case you are wondering when you don't see any effect on power consumption with any better GPU. :)

(In reply to walmartguy from comment #9)

I could imagine that this is really hard to tell with almost any other GPU, as Gemini Lake GPU is both extremely slow and extremely inefficient at the same time. In case you are wondering when you don't see any effect on power consumption with any better GPU. :)

That's exactly the kind of hardware we're targeting here and it sounds perfect for testing :)

Do you think you could check Weston as well for completeness? I'd expect Weston to be the one compositor optimized for this as it's used on many embedded devices and there are some clients seriously using wp_viewporter and subsurfaces to optimize performance there.

I could reproduce it also on Sway, distinct GPU load and SoC power draw increase in both cases.

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.