Open Bug 1525420 Opened 10 months ago Updated 4 months ago

Categories

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

enhancement

Tracking

()

People

(Reporter: kvark, Assigned: kvark)

References

(Blocks 1 open bug)

Details

(Keywords: leave-open)

Attachments

(1 file, 1 obsolete file)

This is a follow-up to the crash issue in https://bugzilla.mozilla.org/show_bug.cgi?id=1522015 , could also be related to another slow-ness bug https://bugzilla.mozilla.org/show_bug.cgi?id=1160130 .

The issue here is to investigate where we are spending time, and what can be done to improve the framerate.

Gecko profile: https://perfht.ml/2RDnTwc

Looks like the Renderer thread is the bottleneck here, spending hundreds of milliseconds per frame to composite it. In particular, 1/3 of the thread time is spent in init_fbos() call. This is unexpected: we should preserve the FBOs across frames and only creates new when necessary.

A GPU capture shows us making 355 draw calls, which is more than we should aim for (up to 100, ideally). This happens due to two reasons:

  • all the blits necessary for picture caching. If caching is unfeasible here, we should improve the heuristic that disables it, so that blits could be avoided.
  • there is a lot of draws of transformed primitives into scissored areas. There are ways to limit the transformed rendering to specific areas without breaking batches, we should look more into it.
  • frame is split across 7 passes, which seems a bit high. We need to investigate if the task graph is deeper than needs to be.

Apparently, the blits are not due to picture caching, as Glenn noted. They are due to our slow handling of mix-blend modes. See also - https://bugzilla.mozilla.org/show_bug.cgi?id=1519718

Crash appears to only occur when picture caching is enabled

Comment on attachment 9041820 [details]
WR don't panic on non-mappable clip rect

Revision D18846 was moved to bug 1522015. Setting attachment 9041820 [details] to obsolete.

Attachment #9041820 - Attachment is obsolete: true
Priority: -- → P4
Assignee: nobody → dmalyshau
Depends on: 1526347

I tested this again with WIP mix-blend rewrite: it feels a bit smoother, but it's not fixed by far. I believe the issues I listed in Comment 1 are still causing the slow.

Blocks: wr-67
No longer blocks: stage-wr-trains
Priority: P4 → P3
Priority: P3 → P2
Priority: P2 → P3
Blocks: wr-68
No longer blocks: wr-67

Use natively supported mix-blend modes, where appropriate.

Attachment #9056182 - Attachment description: [WIP] Use KHR_blend_equation_advanced → Use KHR_blend_equation_advanced for mix-blend mode implementation
Pushed by dmalyshau@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/09753a1a153d
Use KHR_blend_equation_advanced for mix-blend mode implementation r=gw
Keywords: leave-open
Blocks: wr-70
No longer blocks: wr-68
Blocks: wr-perf
No longer blocks: wr-70
You need to log in before you can comment on or make changes to this bug.