1360171 - [meta] UI spends too much time waiting for Direct3D 11 to initialize

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Florian Quèze [:florian]]

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?

Comment 1

[Mike Conley (:mconley) (:⚙️)]

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.

Comment 2

[(no longer active)]

(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!)

Comment 3

[(no longer active)]

(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.

Comment 4

[David Anderson [:dvander] - inactive, e-mail if emergency]

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.

Comment 5

[David Anderson [:dvander] - inactive, e-mail if emergency]

(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.

Comment 6

[David Anderson [:dvander] - inactive, e-mail if emergency]

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.

Comment 7

[David Anderson [:dvander] - inactive, e-mail if emergency]

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.

Comment 8

[(no longer active)]

Florian: ping?

Comment 9

[Florian Quèze [:florian]]

(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

Comment 10

[David Anderson [:dvander] - inactive, e-mail if emergency]

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.