Closed Bug 1370690 Opened 7 years ago Closed 7 years ago

Re-run the sync message telemetry analysis for software GPU process sessions

Categories

(Core :: Graphics: Layers, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: dvander, Assigned: dvander)

References

Details

Attachments

(1 file)

We should have enough historical and present data in Telemetry to compare the rate of UI sync messages when the GPU process is enabled in software mode, versus when it's not enabled.

I'm filing a bug to do this analysis as we did for D3D11-enabled sessions, and assigning myself so I don't forget.
Attached file analysis script.ipynb
Results: https://docs.google.com/spreadsheets/u/1/d/1pmyzB0M5VxWoE3m2sRhl5LF1QbUsjqbFaE1tNT9hxGw/pubhtml#

I took a 2-week sample of Nightly pings. I filtered them down to Windows-only Firefox 56. From there I took four slices:
 (1) D3D11 compositor, GPU process (16,693 sessions)
 (2) D3D11 compositor, no GPU process (3,138 sessions)
 (3) Basic compositor, GPU process (4,894 sessions)
 (4) Basic compositor, no GPU process (1,341 sessions)

For each slice, I took compositor messages from "keyedHistograms/IPC_SYNC_MAIN_LATENCY_MS" and got the ratio of sample count to sessions. Since sync messages under <1ms are not recorded, this is (probably) a better indicator of performance. An average time would be meaningless. Instead we get a ratio of "slow" messages to sessions. Lower is better.

The most important messages are "GetTextureFactoryIdentifier" (sent by content opening a new tab), and "[MapAnd]NotifyChildCreated" (sent by UI registering a new tab). It looks like GetTFI gets a lot better with a compositor process and the UI message is not significantly changed.
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: