Firefox Is Seeing Work On Wayland VA-API Video Acceleration

[treba]

Yup, I mean exclusively 3. The other ones are of course special cases, just like the DRM/HDCP/content-protection case. I guess it's easy to confuse Linux KMS/DRM hardware planes with HW overlays. The hardware plane concept is a bit more encompassing. For instance, the scanout plane isn't really mapped to a specific HW.

Hm ok, then two more questions:

1. Isn't it that "Disable hardware overlays" does increase GPU usage on many devices on Android, showing the power saving potential?
2. Could it be that things are more difficult on android/embeded systems because of tiled rendering and proprietary / buggy drivers? AFAIK things are easier when not using tiled rendering.

Edit: by the way, if webrender got proper compositor integration with wayland and would put e.g. video elements into subsurfaces, which again would then be put into an hardware overlay, that would be pretty much the perfect scenario, no? The preparation work for that has already landed (https://bugzilla.mozilla.org/show_bug.cgi?id=1610738).

[brent]

Hm ok, then two more questions:

Isn't it that "Disable hardware overlays" does increase GPU usage on many devices on Android, showing the power saving potential?

Yeah, sometimes. I think Android doesn't have any page-flipping mechanism without HW overlays, so even fullscreen video playback is fully composited. That is not necessarily the case on desktop Linux. In particular, page-flipping with unredirected rendering is quite normal on X, e.g. for games and video playback.

HW overlays aren't necessarily a power-saver, though. HW overlays trade rendering performance for memory bandwidth. You don't need to render anything with the GPU, but you need to composite in realtime for *every* scanout, which requires a lot of memory accesses, which in turn requires a lot of power. That means you need a rather complex scheme that uses HW overlays for dynamic content and GPU rendering fallback when it becomes static, to consistently save power.

[*]Could it be that things are more difficult on android/embeded systems because of tiled rendering and proprietary / buggy drivers? AFAIK things are easier when not using tiled rendering.

Possibly, but it's all handled by the vendor (https://source.android.com/devices/graphics/hwc), so problems are rare as far as I can see.

Edit: by the way, if webrender got proper compositor integration with wayland and would put e.g. video elements into subsurfaces, which again would then be put into an hardware overlay, that would be pretty much the perfect scenario, no? The preparation work for that has already landed (https://bugzilla.mozilla.org/show_bug.cgi?id=1610738).

Yeah, pretty much, I think. Except for the HW overlays bit.

[treba]

...
HW overlays aren't necessarily a power-saver, though. HW overlays trade rendering performance for memory bandwidth. You don't need to render anything with the GPU, but you need to composite in realtime for *every* scanout, which requires a lot of memory accesses, which in turn requires a lot of power. That means you need a rather complex scheme that uses HW overlays for dynamic content and GPU rendering fallback when it becomes static, to consistently save power.
...

Well that's not super difficult. The compositor knows the surface damage and would only use scanout if the whole (or most of) the surface needs to get repainted anyway. Note that in the WIP MR I posted above that is already the case, it only uses scanout on full damage.
And then the compositor also might want to track a couple of frames so it can avoid weird cases where full and partial damage occur in unfavourable intervals. But such logic exists already in a couple of places in Mutter, e.g. in the overview or the alt-tab switcher to decide whether or not to mipmap a window preview. Anyhow, the decision whether a surface can be put into a overlay has to be made of every frame again (as it has to be checked e.g. if the surface is still on top of everything or if it's partly covered by some other surface). Coming up with some simple algorithm for that should be more than feasible.

...
Yeah, pretty much, I think. Except for the HW overlays bit.

He, funny

[angrypie]

Wayland is a tech demo taken way too seriously because a big Linux player supports it. There's not a single compositor capable of replacing X11 right now.

Wayland compositors are shit because Wayland is shit.

[starshipeleven]

Question:
Firefox is controlled by who?

Mozilla.
Google is paying for a service, not for control, as it can be seen in the kinds of addons you can still use on Firefox (i.e. for example you can install addons that allow you to download from Youtube, while on Chrome you cannot)

[starshipeleven]

Wayland is a tech demo taken way too seriously because a big Linux player supports it. There's not a single compositor capable of replacing X11 right now.

Wayland compositors are shit because Wayland is shit.

Feel free to move to FreeBSD.

[Guest]

Feel free to move to FreeBSD.

Already tried (= installed, no virtual) the version 11.x on my recent PC. Everything, included all my external devices (well, not only mouse and keyboard), run nicely.

[starshipeleven]

Already tried (= installed, no virtual) the version 11.x on my recent PC. Everything, included all my external devices (well, not only mouse and keyboard), run nicely.

Feel free to keep using it

[TemplarGR]

Wayland is a tech demo taken way too seriously because a big Linux player supports it. There's not a single compositor capable of replacing X11 right now.

Wayland compositors are shit because Wayland is shit.

Not true. Besides, these days X is irrelevant, compositors and apps skip it almost entirely. It is a middleman no one actually needs.

[Guest]

Not true. Besides, these days X is irrelevant, compositors and apps skip it almost entirely. It is a middleman no one actually needs.

Can you give me one, or two, serious reasons for using a compositor? All compositors, even in Windows, slow down the PC heavily.