Closed Bug 1686113 Opened 5 years ago Closed 5 years ago

Browser UI hang caused by render task graph v2's new frame graph implementation

Categories

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

defect

Tracking

()

RESOLVED FIXED
86 Branch
Tracking Status
firefox-esr78 --- unaffected
firefox84 --- unaffected
firefox85 --- unaffected
firefox86 + fixed

People

(Reporter: cpeterson, Assigned: gw)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file, 1 obsolete file)

[Tracking Requested - why for this release]:

Web content can hang browser UI in Fx86.

The fuzzer test case attached to bug 1677074 causes the Firefox browser UI to hang:

https://bugzilla.mozilla.org/attachment.cgi?id=9187779

I bisected the hang on Windows 10 and it's a regression from bug 1682365 patch 6 (new frame graph implementation):

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=734f1cbc15b3a2e8e0f4b1e5a6b663e3178204f0&tochange=9e37e5cb4af63f4552ec5ad734a0cd34d8dd2871

Flags: needinfo?(gwatson)
Severity: -- → S3
Priority: -- → P3

I can see the problem here - working on a fix for this today.

Assignee: nobody → gwatson
Flags: needinfo?(gwatson)

The previous traversal strategy for assigning render tasks is very
simple and works fine for normal content. However, it's possible to
create graphs with very deep levels of nesting and dependencies
that cause the pass traversal to not terminate quickly.

Instead, use a more advanced strategy to assign render passes. First,
a topographical sort is performed to split into passes. Then, the
tasks are traversed in topographical order, and assigned to a render
pass that is closest to where they will be used as inputs (this
ensures that we get better render target aliasing, and more sharing
of render tasks within a single target).

Changing the priority to p2 as the bug is tracked by a release manager for the current nightly.
See What Do You Triage for more information

Priority: P3 → P2

The previous traversal strategy for assigning render tasks is very
simple and works fine for normal content. However, it's possible to
create graphs with very deep levels of nesting and dependencies
that cause the pass traversal to not terminate quickly.

This patch contains two changes to fix these cases:

  • Recursion in assign_render_pass will early out if a shorter
    path has been found.
  • Remove recursion from assign_free_pass, iterating each task once.
Attachment #9196532 - Attachment is obsolete: true
Pushed by gwatson@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/369dc8172f69 Fix render pass assignment for complex task graphs. r=nical
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → 86 Branch
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: