Closed Bug 1638466 Opened 4 years ago Closed 2 years ago

Ship out-of-process WebGL on Linux

Categories

(Core :: Graphics: CanvasWebGL, task)

Product:
Core
Component:
Graphics: CanvasWebGL
Platform:
Desktop
Linux
Type:
task

Tracking

()

Status:
RESOLVED FIXED
Milestone:
99 Branch
Project Flags:
Fission Milestone Future
Tracking Flags:
Tracking Status
firefox99 --- fixed

People

(Reporter: jld, Assigned: jld)

References

(Blocks 2 open bugs)

Details

(Keywords: perf-alert)

Attachments

(1 file, 5 obsolete files)

Bug 1638466 - Enable out-of-process WebGL on Linux.
48 bytes, text/x-phabricator-request
Details | Review

Bug 1129492 will need some way for WebGL to work without the content process being an X11 client, which probably means out-of-process WebGL (unless there's some way to use EGL (bug 788319) to have content processes talk directly to the GPU for offscreen rendering and only the compositor talk to the X server, but I don't know enough about how that all works to know if that's even possible).

This bug is to track everything that needs to happen for that to be usable on Linux.

Tracking for Fission Nightly M6c.

Fission Milestone: --- → M6c
See Also: → 1642621
Depends on: 1645010
Depends on: 1646005
No longer blocks: 1607940
Depends on: 1607940
See Also: → remote-webgl

Tracking for Fission M7 Beta milestone. This bug doesn't need to block our Fission Nightly experiment (milestone M6b) because we will exclude Linux users.

Fission Milestone: M6c → M7
Depends on: 1669532
See Also: → 1683420

Nika doesn't think WebGL Remoting needs to block Fission MVP. Non-native theming will remove the biggest use of X11 in content processes and that's probably good enough for Fission MVP.

Fission Milestone: M7 → Future
No longer blocks: 1687853

Early WIP, very basic skeleton status, able to run code from within
SandboxTest inside the new WebGL process.

See Also: → 1720129
Assignee: nobody → lissyx+mozillians
Status: NEW → ASSIGNED

Depends on D119533

Depends on: 1723505
No longer depends on: 1723505

Comment on attachment 9231935 [details]
WIP: Bug 1638466 - Move arguments parsing to ProcessChild

Revision D120241 was moved to bug 1723505. Setting attachment 9231935 [details] to obsolete.

Attachment #9231935 - Attachment is obsolete: true
Attachment #9234015 - Attachment description: WIP: Bug 1638466 - Refactor some GECKO_PROCESS_TYPE() → WIP: Bug 1638466 - Refactor definition and usage of GECKO_PROCESS_TYPE()
Attachment #9234016 - Attachment description: WIP: Bug 1638466 - Refactor some PROCESS_TYPE_* → WIP: Bug 1638466 - Refactor PROCESS_TYPE_* from nsICrashService
Depends on: 1725538

Comment on attachment 9234015 [details]
WIP: Bug 1638466 - Refactor definition and usage of GECKO_PROCESS_TYPE()

Revision D121388 was moved to bug 1726804. Setting attachment 9234015 [details] to obsolete.

Attachment #9234015 - Attachment is obsolete: true

Comment on attachment 9234016 [details]
WIP: Bug 1638466 - Refactor PROCESS_TYPE_* from nsICrashService

Revision D121389 was moved to bug 1726804. Setting attachment 9234016 [details] to obsolete.

Attachment #9234016 - Attachment is obsolete: true
Attachment #9230503 - Attachment description: WIP: Bug 1638466 - Adding WebGL process → Bug 1638466 - Adding WebGL process
Attachment #9230503 - Attachment description: Bug 1638466 - Adding WebGL process → WIP: Bug 1638466 - Adding WebGL process

Depends on D119533

Depends on: 1729656

The current patch stack depends on bug 1723505 and bug 1726804 in an effort to reduce the amount of scaffolding-only required to bring up a new process. I would still like to improve especially around how the process is being launched: the current code was inspired from RDD, and while I like we expose a Promise, I'm wondering if we could make it simpler to handle and track the launch (i.e., get rid of the token thing) and/or maybe expose this promise interface directly within GeckoChildProcessHost.

Depends on: 1731890
Attachment #9230503 - Attachment is obsolete: true
Attachment #9239148 - Attachment is obsolete: true
See Also: → 1380701
Depends on: 1678152

Taking this bug; at this point we shouldn't need a dedicated process or anything, just flipping the pref.

Assignee: lissyx+mozillians → jld
Pushed by jedavis@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/1c322856010d
Enable out-of-process WebGL on Linux. r=jgilbert

https://hg.mozilla.org/mozilla-central/rev/1c322856010d

Status: ASSIGNED → RESOLVED
Closed: 2 years ago
status-firefox99: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 99 Branch

== Change summary for alert #33487 (as of Mon, 07 Mar 2022 11:27:48 GMT) ==

Improvements:

Ratio Test Platform Options Absolute values (old vs new)
149% motionmark_webgl 3DGraphics-WebGL linux1804-64-shippable-qr e10s fission stylo webrender-sw 4.09 -> 10.18
143% motionmark_webgl 3DGraphics-WebGL linux1804-64-shippable-qr e10s fission stylo webrender 4.26 -> 10.34
40% motionmark_webgl 3DGraphics-WebGL linux1804-64-shippable-qr e10s fission stylo webrender 7.10 -> 9.93
21% glvideo Mean tick time across 100 ticks: linux1804-64-shippable-qr e10s fission stylo webrender 21.84 -> 17.17
20% glvideo Mean tick time across 100 ticks: linux1804-64-shippable-qr e10s fission stylo webrender-sw 21.54 -> 17.14

For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=33487

More than 100% improvement seems unlikely, but sure, theoretically possible since it was bogged down to 4fps before!

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: