UI spends too much time waiting for Direct3D 11 to initialize

RESOLVED FIXED

Status

()

RESOLVED FIXED
a year ago
a year ago

People

(Reporter: florian, Assigned: dvander)

Tracking

(Blocks: 2 bugs)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [qf:meta])

See this cold startup profile on the quantum reference machine: https://perfht.ml/2poYI68

updateBrowserRemoteness blocks the ui thread for 2107ms here:
- 1488ms are spent waiting in PGPU::Msg_GetDeviceStatus
- 605ms are spent waiting in PCompositorBridge::Msg_PLayerTransactionConstructor (bug 1350634?)

Ehsan, what's the right component for this?
Flags: needinfo?(ehsan)
This remoteness update will be sidestepped completely if / when bug 1357242 is fixed - though those two IPC messages might just end up moving to earlier in the start-up sequence.
Component: Untriaged → General

Comment 2

a year ago
(In reply to Florian Quèze [:florian] [:flo] from comment #0)
> See this cold startup profile on the quantum reference machine:
> https://perfht.ml/2poYI68
> 
> updateBrowserRemoteness blocks the ui thread for 2107ms here:
> - 1488ms are spent waiting in PGPU::Msg_GetDeviceStatus

This is graphics.  We can morph this bug to track that.

> - 605ms are spent waiting in
> PCompositorBridge::Msg_PLayerTransactionConstructor (bug 1350634?)

Yes this part is just bug 1350634.

(FWIW I've tried to make the case that bug 1350634 should be a [qf:p1] in the past with little success.  Maybe this evidence helps!)
Blocks: 1331674
Component: General → Graphics
Flags: needinfo?(ehsan)
Product: Firefox → Core
Summary: updateBrowserRemoteness is very slow on the first window → PGPU::Msg_GetDeviceStatus is very slow on the first window (can take 1.5 seconds on the reference hardware)

Comment 3

a year ago
(In reply to Mike Conley (:mconley) - PTO on April 28th. from comment #1)
> This remoteness update will be sidestepped completely if / when bug 1357242
> is fixed - though those two IPC messages might just end up moving to earlier
> in the start-up sequence.

The updateRemoteness thing is a red herring.  This is triggered from nsFrameLoader::Show() so we'll trigger it one way or another when displaying a browser window.
I'll investigate this tomorrow. It sounds like the GPU process has either not started yet, or has started and the acknowledgement message is sitting in the UI message loop. Maybe the cause behind bug 1356138.

Our graphics architecture unfortunately relies on knowing precisely what type of compositor we have, and we can't paint until then. But maybe we can either force the GPU process to start earlier, or make device creation asynchronous and only block when someone first asks for a device.
Assignee: nobody → dvander
Status: NEW → ASSIGNED
(In reply to David Anderson [:dvander] from comment #4)
> I'll investigate this tomorrow. It sounds like the GPU process has either
> not started yet, or has started and the acknowledgement message is sitting
> in the UI message loop. Maybe the cause behind bug 1356138.
> 
> Our graphics architecture unfortunately relies on knowing precisely what
> type of compositor we have, and we can't paint until then. But maybe we can
> either force the GPU process to start earlier, or make device creation
> asynchronous and only block when someone first asks for a device.

Also worth noting, when using the GPU process, we use Skia in the UI. In this case the UI process doesn't need to know the compositor type - content does, but that is further along in startup. That might afford us some flexibility.
It's also worth noting: the IPC message is kind of a red herring. If we didn't have this, we would be seeing a huge D3D11 startup cost in the UI process. That's evident in the profile where we're waiting for shaders to initialize for the first composite.

But we should be able to mitigate it.
Summary: PGPU::Msg_GetDeviceStatus is very slow on the first window (can take 1.5 seconds on the reference hardware) → UI spends too much time waiting for Direct3D 11 to initialize
Florian, on my reference machine I didn't see times anywhere near as bad as you did - but they were still bad, in the 300ms range. bug 1360766 was enough to mitigate the problem for me.

After tomorrow's nightly, could you test again and see what your profile looks like? There is potentially more we could do, but it would be good to see what would have the most impact.
Flags: needinfo?(florian)
No longer blocks: 1350634
Depends on: 1350634

Updated

a year ago
Whiteboard: [qf] → [qf:p1]

Comment 8

a year ago
Florian: ping?
(In reply to David Anderson [:dvander] from comment #7)
> Florian, on my reference machine I didn't see times anywhere near as bad as
> you did - but they were still bad, in the 300ms range. bug 1360766 was
> enough to mitigate the problem for me.
> 
> After tomorrow's nightly, could you test again and see what your profile
> looks like? There is potentially more we could do, but it would be good to
> see what would have the most impact.

I'm not sure what you want to look for in the profile exactly, so I'm just going to give you full startup profiles of recent nightlies and let you analyze them.

Here is a cold startup profile captured on today's nightly (June 2nd) on the reference hardware:
https://perfht.ml/2s1yVCs

Here are a few cold startup profiles captured on yesterday's nightly (June 1st) :
https://perfht.ml/2qI7IRt
https://perfht.ml/2qI1P71
https://perfht.ml/2qIhfbe
https://perfht.ml/2qHPnUM
Flags: needinfo?(florian)
Thanks, Florian. I was wondering whether you were still seeing large delays in startup time due to D3D11, but it looks like the answer is no. I'll mark this bug fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: a year ago
Resolution: --- → FIXED

Updated

a year ago
Whiteboard: [qf:p1] → [qf:meta]
You need to log in before you can comment on or make changes to this bug.