Closed Bug 1536515 Opened 2 years ago Closed 3 months ago

Youtube webrender macOS super high GPU usage

Categories

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

67 Branch
defect

Tracking

()

VERIFIED FIXED
mozilla80
Tracking Status
firefox80 --- verified

People

(Reporter: mail, Assigned: miko)

References

(Blocks 2 open bugs)

Details

Attachments

(3 files)

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.

Component: Untriaged → Graphics
Product: Firefox → Core
Blocks: wr-mac
Component: Graphics → Graphics: WebRender
Priority: -- → P3

I expect this probably caused by our terrible texture upload path

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

Flags: needinfo?(mikokm)
Depends on: 1479792
Assignee: nobody → mikokm
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Flags: needinfo?(mikokm)

Depends on D80505

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.
Attachment #9158261 - Attachment description: Bug 1536515 - Part 1: Use the correct OpenGL formats for SurfaceFormat::A8 → Bug 1536515 - Part 1: Use the correct OpenGL formats for SurfaceFormat::A8 and SurfaceFormat::A16
Pushed by mikokm@gmail.com:
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
Regressions: 1651594
See Also: → 1652550
Blocks: 1479792
No longer depends on: 1479792
Flags: qe-verify+

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%).

Status: RESOLVED → VERIFIED
Flags: qe-verify+
Depends on: 1659476
You need to log in before you can comment on or make changes to this bug.