1959878 - Add markers to WindowsVsyncThread for profiling timing issues

Status: ASSIGNED

(Core :: Graphics, enhancement)

Description

[Ashley Hale [:ahale]]

It was very useful to have some profiler markers on the WindowsVsyncThread in Bug 1924932 to understand the excessive CPU usage when the screen is locked, so we should add those permanently - this thread is not in the default set, so it shouldn't add to the size of regular profiles.

When the GFX team are investigating an issue that is suspected to be vsync related we can ask users to add WindowsVsyncThread and record a profile, this may also be useful to Media team.

Comment 1

[Ashley Hale [:ahale]]

Attachment: Bug 1959878 - add markers to WindowsVsyncThread for profiling r?#gfx-reviewers

Comment 2

[Mayank Bansal]

Should this thread be added to the "Graphics" preset?

Comment 3

[Ashley Hale [:ahale]]

Added to triage to discuss if we want WindowsVsyncThread enabled in the Graphics preset.

Comment 4

[Ashley Hale [:ahale]]

NeedInfo - Per triage discussion we think this is useful for Graphics and Media teams, do you have any objections or requested changes on the markers in the patch (comment #1)?

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

There is an r+ patch which didn't land and no activity in this bug for 2 weeks.
:ahale, could you have a look please?
If you still have some work to do, you can add an action "Plan Changes" in Phabricator.
For more information, please visit BugBot documentation.

Comment 6

[Ashley Hale [:ahale]]

My current plan (pending any objections) is to add the WindowsVsyncThread to the Graphics profile preset, and land the new markers code. General consensus in gfx-triage discussion was that this additional info could be useful when we are looking at jank reported by users who provide a profile.

Comment 7

[Markus Stange [:mstange]]

(In reply to Ashley Hale [:ahale] from comment #4)

NeedInfo - Per triage discussion we think this is useful for Graphics and Media teams, do you have any objections or requested changes on the markers in the patch (comment #1)?

Sorry I ignored this needinfo for so long - I don't have any objections. The suggestion from comment 1 definitely seems orthogonal and in no way needs to block the landing of these useful markers.

Comment 8

[Markus Stange [:mstange]]

(In reply to Ashley Hale [:ahale] from comment #6)

My current plan (pending any objections) is to add the WindowsVsyncThread to the Graphics profile preset

Sounds good to me. The purpose of the Graphics preset is to serve the needs of the Graphics team, to make it easier for gfx team members to diagnose gfx-related perf issues that are reported by our users. So any preset changes that help with that are welcome.

Comment 9

[Ashley Hale [:ahale]]

I'll need to figure out how to add it to the Graphics profile preset :)

Looks like the preset is defined at https://searchfox.org/mozilla-central/source/devtools/shared/performance-new/prefs-presets.sys.mjs#102 so I'll add WindowsVsyncThread to the diff

Comment 10

[Markus Stange [:mstange]]

Generally it's preferable to file a separate bug for work that lands separately, to make it easier to track regressions and uplifts.

Comment 11

[Alexandr Kovalenko]

I'm terribly sorry for the inconvenience I will cause you now, but it seems my wife is hitting the same thing as in Bug 1924932, and my marriage (I'm not kidding) depends on how can I workaround this. Could anyone advise how can I prevent Firefox starting to consume CPU (through DWM) when monitor on the laptop shuts off?

Comment 12

[Ashley Hale [:ahale]]

The mechanism of the issue was fixed in that bug, so I'm curious what the new root cause is, we will need the markers added in this patch to figure out why. We're currently in a soft freeze (as we were the last time I worked on this patch) but this only adds logging, so I'll see if I can get this landable.

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/d1799123515c
https://hg.mozilla.org/integration/autoland/rev/231e63dd0f3e
add markers to WindowsVsyncThread for profiling r=gfx-reviewers,profiler-reviewers,canaltinova,lsalzman

Comment 14

[Ashley Hale [:ahale]]

(In reply to Alexandr Kovalenko from comment #11)

I'm terribly sorry for the inconvenience I will cause you now, but it seems my wife is hitting the same thing as in Bug 1924932, and my marriage (I'm not kidding) depends on how can I workaround this. Could anyone advise how can I prevent Firefox starting to consume CPU (through DWM) when monitor on the laptop shuts off?

Attempting to land this debugging patch, so it might show up in Nightly in a day or two, but that's not going to solve your issue, only give you more ways to figure it out (and you'd have to run Firefox Nightly on the laptop to find out).

A couple things you can do to figure this out before then:

• Can you post the about:support of Firefox on the laptop (use the Copy text button at the top of the page) so we know what hardware is involved and whether the WEBRENDER_COMPOSITOR feature is enabled? If you can't, that's okay, but it makes it harder to guess what could be wrong. Also if you do post it, please post it as an attachment on this bug, not merely paste it in a comment.
• Can you run mozregression to find if this is a recent issue and when it was introduced?

There may be prefs (in about:config) that can be toggled to improve this situation, like turning gfx.webrender.compositor to false, or on if it is being blocked for some reason (for that use gfx.webrender.compositor.force-enabled, but presumably if that is necessary it may cause new issues like flickering on some drivers with multiple monitors and different refresh rates). Is this Windows 10 or Windows 11? Some of this advice is easier to give if I saw the about:support to guess what would help, but I hope those are a couple useful leads.

Comment 15

[pstanciu]

https://hg.mozilla.org/mozilla-central/rev/231e63dd0f3e

Comment 16

[Alexandr Kovalenko]

Attachment: about-support.txt

about:support from the affected system

Comment 17

[Alexandr Kovalenko]

Attachment: ff-about-config.png

about:config from the affected system, gfx.webrender.compositor section

Comment 18

[Alexandr Kovalenko]

(In reply to Ashley Hale [:ahale] from comment #14)

(In reply to Alexandr Kovalenko from comment #11)

I'm terribly sorry for the inconvenience I will cause you now, but it seems my wife is hitting the same thing as in Bug 1924932, and my marriage (I'm not kidding) depends on how can I workaround this. Could anyone advise how can I prevent Firefox starting to consume CPU (through DWM) when monitor on the laptop shuts off?

Attempting to land this debugging patch, so it might show up in Nightly in a day or two, but that's not going to solve your issue, only give you more ways to figure it out (and you'd have to run Firefox Nightly on the laptop to find out).

A couple things you can do to figure this out before then:

• Can you post the about:support of Firefox on the laptop (use the Copy text button at the top of the page) so we know what hardware is involved and whether the WEBRENDER_COMPOSITOR feature is enabled? If you can't, that's okay, but it makes it harder to guess what could be wrong. Also if you do post it, please post it as an attachment on this bug, not merely paste it in a comment.
• Can you run mozregression to find if this is a recent issue and when it was introduced?

There may be prefs (in about:config) that can be toggled to improve this situation, like turning gfx.webrender.compositor to false, or on if it is being blocked for some reason (for that use gfx.webrender.compositor.force-enabled, but presumably if that is necessary it may cause new issues like flickering on some drivers with multiple monitors and different refresh rates). Is this Windows 10 or Windows 11? Some of this advice is easier to give if I saw the about:support to guess what would help, but I hope those are a couple useful leads.

Thank you very much!

I've attached requested information - I'm sorry it is not English (haven't figured out how to make Firefox to generate it in English), as well as about:config about gfx.webrender.compositor .

NB: After trial and error it seems what actually helps to prevent this:

• minimize FF
• do MANUAL <Windows Key>+L

If you I do this, then CPU usage (by DWM) does not skyrocket. But it is not enough to do ONLY one of the above - just minimize or just do manual lock.