1360696 - High CPU on Boosted boards video showcase page

Status: NEW

(Core :: Audio/Video: Playback, defect, P3)

Description

[Jeff Griffiths (:canuckistani) (:⚡︎)]

STR:

1. open [1] in Chrome and Nightly
2. click on the braking and acceleration thumbnail at the bottom left ( video should start playing as the background to the page, and also keep playing in the thumbnail )
3. click on the watch video button ( video should start playing in a shadowbox, and keep playing in the other two background spots )

ER: we should exhibit similar or better cpu usage in this case than chrome
AR: we seem to use close to double the cpu as chrome



[1] https://boostedboards.com/video-showcase/

Comment 1

[Chris Peterson [:cpeterson]]

cpearce, does this look like an issue with compositing the videos or decoding them?

Jeff said on IRC:

it's an extreme case, 3 video playback streams on different layers, but really highlights a difference in cpu. I looked at Safari and it seems to be a little lower cpu than chrome. in all cases there is high cpu usage in VTDecoderXPCService on macOS. there is *also* high cpu usage in all browsers, just much higher in Nightly

Comment 2

[Till Schneidereit [:till]]

This site has high CPU usage even with only the small video playing - in all browsers. It's worse in Nightly, but not nearly as much as with all three videos playing. One difference is that even with one video playing, Gecko creates high load on the GPU in addition to the CPU. The GPU load seems to be fairly similar to what's caused by HW-decoding the same video (as tested by embedding it in an otherwise blank page).

For Safari and Chrome, GPU usage is almost nonexistent with one video playing, but rises significantly with two or three.

Comment 3

[Chris Pearce [:cpearce (Not reading bugmail)]]

Cleopatra profile of the STR:
https://perfht.ml/2oNHoZy

We're using 3 times the memory on my Win32 Nightly too.

This looks like a graphics issue to me; I don't see media stuff showing up in the profile.

Bas: Any ideas what's going on here?

Comment 4

[Bas Schouten (:bas.schouten)]

(In reply to Chris Pearce (:cpearce) from comment #3)
> Cleopatra profile of the STR:
> https://perfht.ml/2oNHoZy
> 
> We're using 3 times the memory on my Win32 Nightly too.
> 
> This looks like a graphics issue to me; I don't see media stuff showing up
> in the profile.
> 
> Bas: Any ideas what's going on here?

So we're spending a lot of time waiting for the GPU, because of some technicalities in our code, this causes us to spin the CPU if the GPU is more than 1 frame behind and there are no threads waiting for be executed. By changing the Sleep(0) in CompositorD3D11::EndFrame to a Sleep(1), you can significantly reduce the CPU usage. I've not done this yet as it's never seemed like a high enough priority to justify whatever unintended side-effect this could have.

High memory usage might be due to Media and graphics generally holding onto a ridiculous amount of frames (much more than media is intending to), I mentioned this to Jean-Yves a while ago but we never quite got to the bottom of it.

Comment 5

[Jeff Griffiths (:canuckistani) (:⚡︎)]

(In reply to Bas Schouten (:bas.schouten) from comment #4)
> (In reply to Chris Pearce (:cpearce) from comment #3)
...
> > Bas: Any ideas what's going on here?
> 
> So we're spending a lot of time waiting for the GPU, because of some
> technicalities in our code, this causes us to spin the CPU if the GPU is
> more than 1 frame behind and there are no threads waiting for be executed.
> By changing the Sleep(0) in CompositorD3D11::EndFrame to a Sleep(1), you can
> significantly reduce the CPU usage. I've not done this yet as it's never
> seemed like a high enough priority to justify whatever unintended
> side-effect this could have.

I would love to prioritize this but I need to know what kinds of unintended side-effects we would have to spend time fixing in order to make it work well. Based on your explanation this problem is a generic one that would cause high CPU on any system where the GPU is having trouble rendering content, correct?

Can we get a try build with the change and see if it has problems? It seems like the change is simple enough to make unless I'm missing something. Happy to test myself.

Comment 6

[Bas Schouten (:bas.schouten)]

(In reply to Jeff Griffiths (:canuckistani) (:⚡︎) from comment #5)
> (In reply to Bas Schouten (:bas.schouten) from comment #4)
> > (In reply to Chris Pearce (:cpearce) from comment #3)
> ...
> > > Bas: Any ideas what's going on here?
> > 
> > So we're spending a lot of time waiting for the GPU, because of some
> > technicalities in our code, this causes us to spin the CPU if the GPU is
> > more than 1 frame behind and there are no threads waiting for be executed.
> > By changing the Sleep(0) in CompositorD3D11::EndFrame to a Sleep(1), you can
> > significantly reduce the CPU usage. I've not done this yet as it's never
> > seemed like a high enough priority to justify whatever unintended
> > side-effect this could have.
> 
> I would love to prioritize this but I need to know what kinds of unintended
> side-effects we would have to spend time fixing in order to make it work
> well. Based on your explanation this problem is a generic one that would
> cause high CPU on any system where the GPU is having trouble rendering
> content, correct?
> 
> Can we get a try build with the change and see if it has problems? It seems
> like the change is simple enough to make unless I'm missing something. Happy
> to test myself.

Just change the Sleep(0) in EndFrame into a Sleep(1) (or wherever that query check has moved since then).

It's important to note this causes high CPU -unless- the system has other things to do, Sleep(0) yields the thread's time slice and just returns right a way if the system has no waiting threads. i.e. the current situation just takes up battery and shows up worse in task manager, but -doesn't- cause any user-facing negative effects beyond that.

Comment 7

[Bas Schouten (:bas.schouten)]

And yes, you are correct, whenever the GPU is busy, this will show up. The Compositor thread will just swallow a whole core.

Comment 8

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

Chrome/Firefox are using VP9 which reduces the network bandwidth for the YouTube video. Safari CPU usage isn't comparable because it uses H.264. Firefox will use H.264 on slower machines if hardware acceleration is available (e.g. on Mac).

Bas - it would be better not to spin the CPU. What are the likely consequences to changing to a Sleep(1)? Is there a better way to fix the issue?

Comment 9

[Ryan VanderMeulen [:RyanVM]]

(In reply to Bas Schouten (:bas.schouten) from comment #6)
> Just change the Sleep(0) in EndFrame into a Sleep(1) (or wherever that query
> check has moved since then).

Looks like the code has changed. Is this the right place now?
https://dxr.mozilla.org/mozilla-central/source/gfx/layers/d3d11/HelpersD3D11.h#26