1573113 - https://propjockey.github.io/DOMinion-build-demo/ breaks webrender

Status: NEW

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

Description

[Nicolas Silva [:nical]]

Attachment: Screenshot

The demo runs pretty slow on an intel integrated GPU but more importantly, some frames are corrupted to the point that the text runs on the tabs render incorrectly as well (see the black boxes on the screenshot).

Comment 1

[Mayank Bansal]

I got a crash on this page : https://crash-stats.mozilla.org/report/index/6dbcfa35-0004-4806-b089-25aa40190812
And nightly is not releasing the memory even after triggering manually.

Comment 2

[Mayank Bansal]

Attachment: memory-report.json.gz

Comment 3

[Dzmitry Malyshau [:kvark]]

Mayank, your crash is in "ClientMultiTiledLayerBuffer::Update", which I think is non-WebRender, while the original bug is about WebRender. Could you provide "about:support" output just to make sure? We'll likely need a separate bug filed to track this crash.

Comment 4

[Mayank Bansal]

Attachment: aboutsupport_before_crash.txt

I do use WR by default. However, I think it fails on this page, and then falls back to the D3D11 thing. And then crashes

Before the crash, I was using WR
After the crash, I was on D3D11

Comment 5

[Mayank Bansal]

Hopefully a better crash report :
https://crash-stats.mozilla.org/report/index/cb7092ba-a523-4ba7-a25f-dc7950190812

Comment 6

[Mayank Bansal]

Attachment: aboutsupport_after_crash.txt

this is the about:support after the tab crashed

Comment 7

[Dzmitry Malyshau [:kvark]]

Thank you!

(#80): CP+[GFX1]: [Tiling:Client] Failed to allocate a TextureClient

Failing to create a texture for some reason? Adding Andrew and bumping the priority.

Comment 8

[Mayank Bansal]

If I disable picture-caching, the browser stays alive longer, and even after the tab crashes, I still see the compositor as WR

Comment 9

[Darkspirit]

(Mayank Bansal from comment #1)

And nightly is not releasing the memory even after triggering manually.

Tab was not black on Win10/GTX1060, but it almost froze my desktop.

Comment 10

[Andrew Osmond [:aosmond] (he/him)]

On Linux Intel, I am seeing WR crashes like:

https://crash-stats.mozilla.org/report/index/fb20ac8c-65ed-401f-81f9-54c4f0190813
https://crash-stats.mozilla.org/report/index/ef31f01d-10ef-414c-8342-8d6130190813
https://crash-stats.mozilla.org/report/index/3d29d7f2-3c89-4290-926d-2aa690190813

Looks like the driver bails out early via exit, probably due to an OOM, and triggers the release assert because we are freeing things from the static store on the wrong thread as a result.

It runs very slowly with the basic compositor for me, but it does run.

Comment 11

[Andrew Osmond [:aosmond] (he/him)]

Gankra found that WR was using 20GB of texture memory on her machine but doesn't crash. I'm not too worried about the texture host allocation failure log entries because that is a recoverable error -- it seems to chug along with basic compositor, and I suspect the crashes Mayank is seeing after WR is shutdown are mostly fallout from WR crashing and not being fully cleaned up yet.

kvark, thoughts on the texture memory usage?

Comment 12

[Dzmitry Malyshau [:kvark]]

There is no way for us to force the limit on the number of textures used. One can always construct a page that either has a lot of images displayed, or involves a lot of render targets (multiple large blurs). We need to know when to give up, basically. Correspondingly, there should be multiple places through the code that check if we are trying to allocate too much of GPU memory:

• at scene building we could check the total image size on GPU that is about to be uploaded
• after frame building we could estimate the max render target memory we'll need to render it

Comment 13

[Jessie [:jbonisteel] pls NI]

Nical, does this still look like an issue?

Comment 14

[Nicolas Silva [:nical]]

Oh yeah! Still very much bringing WebRneder to its knees.

Comment 15

[Mayank Bansal]

This no longer OOM's after bug 1643201 , and specifically https://phabricator.services.mozilla.com/D78204