1536515 - Youtube webrender macOS super high GPU usage

Status: VERIFIED FIXED

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

Description

[Nino Floris]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:67.0) Gecko/20100101 Firefox/67.0

Steps to reproduce:

Running a youtube video with webrender on a macbook pro 2015 15" (intel iris pro) on firefox deveolper edition 67b2.

Actual results:

Puts GPU usage at 80% vs safari at a comfortable 50 or under. Besides that the latent usage is also higher while the tab/firefox process is not actually visible, just running audio. In that case there's still about a 20 to 30% difference vs safari. The difference between a machine that feels sluggish and one that feels ok.

Firefox is pegging the GPU too much leaving almost nothing to the system to render app switches, scrolling in other apps etcetera, leaving an extremely poor UX.

With webrender off though it's still higher than safari (about 10%) but it's workable at least, mainly because when the video is not visible firefox uses about the same compared to safari.

Expected results:

This must be better before webrender is turned on by default on macOS.

Comment 1

[Jeff Muizelaar [:jrmuizel]]

I expect this probably caused by our terrible texture upload path

Comment 2

[Jessie [:jbonisteel] pls NI]

Miko, this could be an interesting use case for texture upload improvements.

Comment 3

[Miko Mynttinen]

Attachment: Bug 1536515 - Part 1: Use the correct OpenGL formats for SurfaceFormat::A8 and SurfaceFormat::A16

Comment 4

[Miko Mynttinen]

Attachment: Bug 1536515 - Part 2: Add constructors that take GLContext to GLTextureSource and DirectMapTextureSource

Depends on D80504

Comment 5

[Miko Mynttinen]

Attachment: Bug 1536515 - Part 3: Add RenderExternalTextureHost

Depends on D80505

Comment 6

[Miko Mynttinen]

The current video texture upload behavior of WebRender is the following:

• Video data is passed to WebRender as a pointer to shared memory
• WebRender allocates a PBO for the pixel data
• WebRender maps the PBO and copies the pixel data from the shared memory to the PBO
• OpenGL copies the PBO content to the texture (glTexImage2D)

These patches try to improve WebRender video playback by avoiding a copy during texture upload. This is done by uploading the pixel data directly from the shared memory to a texture, instead of going through a PBO. The copy is avoided with the use of Apple Client Storage OpenGL extension.

There are at least two ways to implement this and it is not immediately obvious which one is better.

Textures managed inside WebRender
Difficult/missing parts:

• An immediate upload path for persistent textures that bypasses texture cache and supports client storage
• Texture updates that avoid allocations and just call glTexImage2D
• The lifetime of the shared memory pointer inside WebRender needs to match the lifetime of texture referencing it

Textures managed outside WebRender (these patches)
Since Gecko already supports Client Storage with OpenGL backend, this was easier to implement.

• RenderExternalTextureHost wraps DirectMapTextureSource that creates OpenGL textures and uploads the pixel data from the shared memory surface.
• The resulting OpenGL texture handle is passed to WebRender.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5b0cde54f206
Part 1: Use the correct OpenGL formats for SurfaceFormat::A8 and SurfaceFormat::A16 r=jgilbert
https://hg.mozilla.org/integration/autoland/rev/ce204516752c
Part 2: Add constructors that take GLContext to GLTextureSource and DirectMapTextureSource r=nical
https://hg.mozilla.org/integration/autoland/rev/8cf433954cb5
Part 3: Add RenderExternalTextureHost r=sotaro

Comment 8

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/5b0cde54f206
https://hg.mozilla.org/mozilla-central/rev/ce204516752c
https://hg.mozilla.org/mozilla-central/rev/8cf433954cb5

Comment 9

[Cristian Fogel [:cfogel]]

Confirmed the issue with 67.0b3-macOS 10.15.5, after a few seconds of playback and page light-scrolling, CPU %usage skyrocket-ed by 60%.
Good improvement can be observed on 80.0b6; spikes occur on actions; but they're falling back way quicker
(idles at @6% as opposed to 26-80%).