1717902 - Performance profiling

Status: NEW

(Core :: Graphics: WebRender, task, P4)

Description

[Robert Mader [:rmader]]

Tracker bug for profiling.

Comment 1

[Robert Mader [:rmader]]

(In reply to Vincent from bug 1617498 comment 15)

Robert I have a 4K display running off Intel UHD 620 graphics (Whiskey lake). Do you know of a good (scientific) profiling utility for GNOME/Fedora so I could do some testing? Perhaps there's a way of logging intel_gpu_top output to a file.

Unfortunately I don't now much about this yet. Two things that may be helpful are the Firefox internal profiler[1] and Sysprof for Gnome-Shell/Mutter[2] to find hotspots, but that's maybe not what you are looking for.

I see in this blog macOS has a tool to show the area being repainted. Are you aware of such a tool on Linux/Wayland?

Gnome has some inbuild tools, but they are not yet accessible via a nice app (hopefully in the future[3]). If you open looking glass via alt+f2 -> lg -> enter, you can enable some debug overlays:

• damage region: Meta.add_clutter_debug_flags(0, Clutter.DrawDebugFlag.PAINT_DAMAGE_REGION, 0) / Meta.remove_clutter_debug_flags(0, Clutter.DrawDebugFlag.PAINT_DAMAGE_REGION, 0)
• opaque regions: Meta.add_debug_paint_flag(Meta.DebugPaintFlag.OPAQUE_REGION) / Meta.remove_debug_paint_flag(Meta.DebugPaintFlag.OPAQUE_REGION)

P.S.: note that the damage region overlay currently shows any damage done in Mutter - not just surface damage reported by the client. That means if Firefox moves a tile via Wayland APIs but doesn't repaint the content, the whole area will still get repainted. We don't yet have a indicator for pure client surface/buffer damage in Gnome. OTOH, Firefox has overlays for this build in somewhere.

1: https://profiler.firefox.com/
2: https://blogs.gnome.org/chergert/2020/03/15/how-to-use-sysprof-to-part-ii/
3: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3968

Comment 2

[Vincent Chernin]

Thanks for all the info! I played around with the various tools you suggested, unfortunately it didn't get me very far. The looking glass view is especially neat, I'm just not sure what we can learn from it yet. Maybe profiling + screen casting with the looking glass view would help correlate high cpu/gpu usage with certain patterns of overlays. I think there's definitely uses for those tools.

I did have some sucess with intel_gpu_top. It can output to JSON (thanks man page), and I was able to (somewhat manually) benchmark forty.gnome.org. It seemed like a decent (animation heavy) site to start off. An extension scrolled all the way down the page, then up the page, and then down again automatically (800px/s).

There are several issues I want to sort out before I'm more confident in my results:

• A more reliable way to get Firefox to autoscroll down and up automatically. I used the Foxscroller FF extension which I found to not work very consistently.
• A better way to graph and analyze the JSON than the website I found. I'd like averages, perhaps the total sum of energy used over time as well. I see a lot of spikes, which makes it hard to say what's going on.
• A script should start both Firefox and the logger at the same time, I tried doing this but I couldn't get it to work, it's surely doable though.
• It would be nice to automatically flip the preference as well (maybe 2 Firefox profiles?)
• More websites to test on is definitely needed.
• Test different window sizes, i.e. maximized, half sized, quarter, etc.

Nevertheless here is the graph of time versus total package power (cpu+gpu), with gfx.webrender.compositor.force-enabled enabled, and disabled.

Data (should) be taken every 10 ms. Command used was sudo intel_gpu_top -s 10 -J -o testfile and MOZ_ENABLE_WAYLAND=1 ./firefox https://forty.gnome.org. Note the first section of the first picture is very low due to me running the commands seperately (Firefox hadn't opened yet). Also enclose the entire JSON with [] otherwise it will be invalid. Tested on Nightly Tarball 91.0a1 (2021-06-23) (64-bit). Other apps were open, but nothing major graphically was happening (Probably worth closing them though once I've got the procedure figured out). about:support: WebRender and Wayland enabled.

Again I'm not very confident that these results are meaningful, more automatation and other fixes are needed before then. Still I hope this is helpful :)

Comment 3

[Robert Mader [:rmader]]

Thanks for trying stuff out :)
Note: animation heavy websites like forty.gnome.org are rather unlikely to benefit here. They likely benefit from Webrender, but not from compositor integration, as most of the content needs to get redrawn.

The areas where I'd expect the biggest improvements are:

• scrolling (mostly) static websites like wikipedia but also, to a lesser degree, youtube
• websites containing (scaled) videos

Comment 4

[Robert Mader [:rmader]]

Comment from Glenn on Matrix:

Wow, with MOZ_ENABLE_WAYLAND=1, gfx.webrender.compositor.force-enabled, widget.wayland.fractional_buffer_scale the future is nearly here! I can see a little bit of blurriness, I think. It's hard to say conclusively, it doesn't look quite as crisp on wayland with fractional scaling as it does on X11, but it's close. There's a few artifacts too at 150% (especially when the megabar dropdown shows up). In general though, a massive improvement on running firefox under xwayland with fractional scaling enabled, and the performance with the native compositor enabled is fantastic 👍️

And:

Seeing average GPU times inside WR of ~0.1-0.2 ms when playing a youtube video and scrolling at 4k on a AMD Radeon (TM) Pro WX 3200 Series GPU

Comment 5

[walmartguy]

Robert, as requested, I've reported a new bug about increased GPU load with WebRender Compositor on Wayland:
https://bugzilla.mozilla.org/show_bug.cgi?id=1750457
At this occasion, I've also tested Sway and found it to be affected the same as KWin.