Open Bug 1501545 Opened 6 years ago Updated 7 months ago

testcase from bug 1123075 performs poorly on WR, and takes several GB of RAM on higher count

Categories

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

Product:
Core
Component:
Graphics: WebRender
Type:
defect

Tracking

()

Status:
REOPENED

People

(Reporter: mayankleoboy1, Unassigned)

References

(Blocks 2 open bugs)

Details

Crash Data

Attachments

(2 files, 1 obsolete file)

memory-report.json.gz
91.15 KB, application/x-gzip
Details
testcase.html
3.63 KB, text/html
Details
Attached file memory-report.json.gz —
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0 Steps to reproduce: enable WR open the testase from bug 1123075 https://bugzilla.mozilla.org/attachment.cgi?id=8550906 Actual results: memory increases continuously Browser is extremely slow to respond to clicks Expected results: reasonable memory use Smooth performance
See Also: → 1123075
Blocks: stage-wr-trains
Priority: -- → P4
The memory use has reduced. With the "1" case in the dropdown, the memory stabilises around the 600-700mb mark, Performance is not very good. Chrome is much better. WR profile : https://perfht.ml/2z3wS3d cc glen, as the profile is somewhat unique, in the WRRenderBackend thread, in the sense that the this is the first time I have seen more time spent in prim_store than in the WaitForThreadAlertbyID
Summary: testcase from bug 1123075 chokes WR and the brower by increasing the memory continuously → testcase from bug 1123075 performs poorly on WR
here is a profile with the setting to "7" in the testcase dropdown : https://perfht.ml/2z0gII6
Attached file testcase.html —
Summary: testcase from bug 1123075 performs poorly on WR → testcase from bug 1123075 performs poorly on WR, and takes several GB of RAM on higher count
Blocks: wr-67
No longer blocks: stage-wr-trains
Priority: P4 → P3
Blocks: wr-68
No longer blocks: wr-67
Blocks: wr-70
No longer blocks: wr-68
No longer blocks: wr-70

This test case reliably causes picture cache tiles to turn white for me on linux + nvidia. I've seen at least one bug on file where this white tile issue was hard to reproduce so this might be worth looking into.

Flags: needinfo?(gwatson)

I tested this on a Linux machine with an nVidia GTX 1050 and also an AMD 5700XT. I also tried on a Win10 machine with the GTX 1050.

I didn't see any missing / white tiles unfortunately.

The performance sure was terrible though, we should definitely look into this. On level 7, it also eventually panics with:

Attempting to allocate a texture of size 1024x8600 above the limit

And reverts to the Basic compositor.

Flags: needinfo?(gwatson)

After bug 1637953 landed, the testcase turns white after 10 seconds or so, with an error of allocating a large texture. And reverts to the d3d11 compositor

Crash Signature: [@ cs_blur_COLOR_TARGET_frag::swgl_drawSpanRGBA8]
Crash Signature: [@ cs_blur_COLOR_TARGET_frag::swgl_drawSpanRGBA8] → [@ cs_blur_COLOR_TARGET_frag::swgl_drawSpanRGBA8] [@ webrender::render_task_graph::assign_render_pass ]

On my (beefy) linux desktop, frame building is the slowest part on the webrender side of things. I'm not seeing glitches anymore.

Recent profile: https://share.firefox.dev/3IVhoR9

Blocks: wr-frame-building-perf
No longer blocks: wr-perf
Blocks: 1782834
Severity: normal → S3

Closing because no crashes reported for 12 weeks.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME

I think this bug was closed by mistake

Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Attachment #9386963 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: