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)
Core
Graphics: Layers
Tracking
()
RESOLVED
FIXED
People
(Reporter: dvander, Assigned: dvander)
References
Details
Attachments
(1 file)
(deleted),
text/plain
|
Details |
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.
Assignee | ||
Comment 1•7 years ago
|
||
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.
Assignee | ||
Updated•7 years ago
|
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.
Description
•