Open Bug 1573113 Opened 4 months ago Updated Last month


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




Tracking Status
firefox-esr60 --- disabled
firefox-esr68 --- disabled
firefox68 --- affected
firefox69 --- affected
firefox70 --- affected


(Reporter: nical, Unassigned)


(Blocks 1 open bug, )


(Keywords: correctness, memory-footprint, perf)


(4 files)

Attached image 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).

Priority: -- → P3

I got a crash on this page :
And nightly is not releasing the memory even after triggering manually.

Attached file memory-report.json.gz

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.

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

this is the about:support after the tab crashed

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.

Priority: P3 → P1

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

(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.

On Linux Intel, I am seeing WR crashes like:

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.

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?

Flags: needinfo?(dmalyshau)
Blocks: wr-71
No longer blocks: wr-69

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
Flags: needinfo?(dmalyshau)
No longer blocks: wr-71
You need to log in before you can comment on or make changes to this bug.