1769747 - Poor performance on 360 video which uses WebGL

Status: RESOLVED FIXED

(Core :: Graphics: CanvasWebGL, defect, P1)

Description

[aymedeyacoan]

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

Steps to reproduce:

We're seeing poor performance on Vimeo while viewing very high quality 360 video.

It looks like Vimeo do 360 by decoding a large video, and using webgl to transform it to a 2D viewport.

I'm getting this error on my MacBook Pro 2020

STR:

1. Load 360 video on Vimeo, i.e.: https://vimeo.com/channels/360vr/355120249
2. Select 4K from the cog menu
3. You can see the lower framerate of the video in comparison with chrome.

Actual results:

Video has low framerate in comparison to chrome

Expected results:

The video should have a good framerate

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Canvas: WebGL' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:jgilbert, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 3

[Kelsey Gilbert [:jgilbert]]

I will check.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:jgilbert, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 5

[adam.niederer]

I can reproduce this in a fresh install of Firefox 103.0b3 on X11 (Arch Linux). Issue is reproducible with with both media.ffmpeg.vaapi.enabled set and unset. Anecdotally, I've noticed this being the case on my personal install for a few years.

I can't find any hardware bottleneck, either. Most used CPU core is sitting at 10% and 3d/codec usage is below 15%..

I'm not sure if YouTube's underlying 360 video playback mechanism is similar to Vimeo's, but this URL appears to offer an exacerbated case of the above issue when the quality is set to 4320s (8K). 1-2FPS on my machine, <30% CPU/GPU/highest-core usage, regardless of VAAPI usage.

https://www.youtube.com/watch?v=L_tqK4eqelA

Comment 6

[Kelsey Gilbert [:jgilbert]]

With webgl.perf.max-warnings: -1: (on mac)

WebGL perf warning: WebGL warning: tex(Sub)Image[23]D: Missed GPU-copy fast-path: format is not RGBA
WebGL perf warning: WebGL warning: texImage: Conversion requires pixel reformatting. (26->15)

Comment 7

[Kelsey Gilbert [:jgilbert]]

Windows:

WebGL perf warning: WebGL warning: tex(Sub)Image[23]D: Missed GPU-copy fast-path: format is not RGBA
WebGL perf warning: WebGL warning: texImage: Conversion requires pixel reformatting. (27->15)

Comment 8

[Kelsey Gilbert [:jgilbert]]

Windows, but more helpful:

WebGL perf warning: WebGL warning: tex(Sub)Image[23]D: Missed GPU-copy fast-path: format is not RGBA
WebGL perf warning: WebGL warning: texImage: Conversion requires pixel reformatting. (BGRA8->RGB8)
WebGL perf warning: WebGL warning: <Present>: [webgl.perf.spew-frame-allocs] 1 data allocations this frame.

Comment 9

[Kelsey Gilbert [:jgilbert]]

Attachment: Bug 1769747 - Support non-RGBA video-to-texture fastpath.

Comment 10

[Kelsey Gilbert [:jgilbert]]

I'm having second thoughts about opening up formats this widely. Maybe I should merely add RGB8 for now? That would be safer. I'm worried about requests for e.g. LUMINANCE or RG. I could add tests, but drivers gonna be drivers, and these other formats seem pretty unlikely to be needed.
I should also definitely check to see if I can simply render to RGB8, because that's what people expect.
It would be good to have telemetry on RGB8 renderability.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0a2985a48339
Support non-RGBA video-to-texture fastpath. r=gfx-reviewers,nical

Comment 12

[Atila Butkovits]

Backed out for causing gl failures.

Backout link: https://hg.mozilla.org/integration/autoland/rev/7a732fe218b0211adb611ad9617f54dadb5baf78

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&selectedTaskRun=S7RHUw8dRSO85qz7r66ETg.0&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&revision=0a2985a48339d6b8829e191a70597b1cd088166a

Failure log: https://treeherder.mozilla.org/logviewer?job_id=392250536&repo=autoland&lineNumber=3154

Comment 13

[BugBot [:suhaib / :marco/ :calixte]]

There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:jgilbert, could you have a look please?
If you still have some work to do, you can add an action "Plan Changes" in Phabricator.
For more information, please visit auto_nag documentation.

Comment 14

[Hurair]

I visite a website and the translation was just ok from the browser
PS. It was a home care services niche website
peaceinhomehealthcare.com

Comment 15

[Hurair]

I visite a website and the translation was just ok from the browser
PS. It was a home care services niche website
www.peaceinhomehealthcare.com

Comment 17

[Martin Stránský [:stransky] (ni? me)]

May https://phabricator.services.mozilla.com/D167159 be used as minimal patch here?

Comment 18

[Kelsey Gilbert [:jgilbert]]

I believe this was fixed by bug 1655101.