1614734 - Time spent stuck in RendererOGL::WaitForGPU()

Status: NEW

(Core :: Graphics: WebRender, defect, P3)

Description

[Jeff Muizelaar [:jrmuizel]]

Here's a profile from scrolling YouTube on an Intel GPU at 4K @ 60Hz. https://perfht.ml/3bxpizp

There are some major janks that seem to correspond to time spent in WaitForGPU()

Comment 1

[Sotaro Ikeda [:sotaro]]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #0)

There are some major janks that seem to correspond to time spent in WaitForGPU()

This means that gpu is busy for tasks. From previous experiences, removing WaitForGPU() seems not address the scrolling problem.
:mattwoodrow, can you comment about it?

Comment 2

[Sotaro Ikeda [:sotaro]]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #0)

Here's a profile from scrolling YouTube on an Intel GPU at 4K @ 60Hz. https://perfht.ml/3bxpizp

There are some major janks that seem to correspond to time spent in WaitForGPU()

In the past, we tested to remove WaitForGPU(). In this case, the wait was moved to IDXGISwapChain::Present() in RenderCompositorANGLE::EndFrame(). WaitForGPU() is better place to wait than EndFrame(). Though I did not re-test it with DC compositor.

And current TextureHost recycling depends on WaitForGPU() call. If we want to remove the wait, we need to think about recycling mechanism.

Comment 3

[Jeff Muizelaar [:jrmuizel]]

Also, have we looked at using DXGI_SWAP_CHAIN_FLAG_FRAME_LATENCY_WAITABLE_OBJECT instead of our current implemention?

Comment 4

[Sotaro Ikeda [:sotaro]]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #3)

Also, have we looked at using DXGI_SWAP_CHAIN_FLAG_FRAME_LATENCY_WAITABLE_OBJECT instead of our current implemention?

I tried bit at Bug 1500017 Comment 6 in the past. And it caused a wait in RenderCompositorANGLE::BeginFrame() by calling WaitForSingleObjectEx(). And I did not see a performance improvement during investigating triple buffering swap chain usage.

DXGI_SWAP_CHAIN_FLAG_FRAME_LATENCY_WAITABLE_OBJECT is a swap chain specific solution. Then we could not use it for native compositor, since it does not use swap chain.