1626827 - GraphicsCriticalError: Attempting to allocate a texture of size 8960x768 above the limit on soraapp.com

Status: VERIFIED FIXED

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

Description

[Brad Werth [:bradwerth]]

Steps to Reproduce

1. Use a profile with pref gfx.webrender.all set to true.
2. Navigate to https://soraapp.com, click "Find my school".
3. After the page loads, click bottom "My school isn't listed".

Expected results: animation plays and next page loads.
Actual results: Crash with log entry:

Crash Annotation GraphicsCriticalError: |[0][GFX1-]: Attempting to allocate a texture of size 8960x768 above the limit, trimming (t=149.379)

Comment 1

[Dzmitry Malyshau [:kvark]]

Thank you for filing!
It's annoying to crash the GPU process here, we should fix that sooner.
Perhaps, the problem is somewhere here - https://searchfox.org/mozilla-central/rev/4ccefc3181f9d237ef4ca8bd17b4e7c101ddf7b5/gfx/wr/webrender/src/renderer.rs#5411

We basically have a disagreement between the frame builder's point of view on required target size and the renderer's. Should be relatively straightforward to fix, given this steady test case (thanks!).

Comment 2

[Dzmitry Malyshau [:kvark]]

Looked at this some more - it appears to be related to bug 1613260. Here in the code we have the device size width ~9000, which is above the maximum texture size.
The raster config looks like this:

$6 = webrender::picture::RasterConfig {
  composite_mode: webrender::picture::PictureCompositeMode::Filter(<error reading variable>),
  surface_index: webrender::picture::SurfaceIndex (
    7
  ),
  establishes_raster_root: false,
  root_scaling_factor: 1
}

This means adjust_scale_for_max_surface_size doesn't want to deal with it. The task has a surface associated, but it's placed at the root spatial node, and the surface doesn't establish a raster root. So the code behaves as if this would be handled by the clipping to the screen size at some point. This doesn't happen in this case.

More generally, we can have tasks that are in screen space but need more bounds than the screen, e.g. if something is heavily blurred. Is there a plan to deal with those?

I think what we should be considering more inputs to adjust_scale_for_max_surface_size. If we see that there is no raster root, we should still do the scaling in order to fit into the maximum texture size of the device. How does that sound to you, Bert, Glenn?

Comment 3

[Dzmitry Malyshau [:kvark]]

Attachment: Force WR picture tasks to fit into max target size

this is an attempt to handle tasks outside of the device bounds,
that belong to surfaces not establishing raster roots.

I suspect that the scaling we are now setting up in adjust_scale_for_max_surface_size
doesn't work properly, since the function was assumed to only affect the raster-rooted
surfaces. But it does fix the crash we have.

Comment 4

[Bert Peers [:bpeers]]

Hi Dzmitry, thanks for catching this.
adjust_scale_for_max_surface_size only kicks in when establishing a raster root because it is intended to replace the following safety check in picture.rs:

if raster_config.establishes_raster_root
     && (surface_rect.size.width > MAX_SURFACE_SIZE
            || surface_rect.size.height > MAX_SURFACE_SIZE)

So, I'm kind of hoping that the crash also happens with the old code, otherwise there's a bit of a mystery how changing the behaviour of raster roots has changed the behaviour of non-raster-roots.
The old code path is still in there, by setting frame_context.debug_flags to DebugFlags::DISABLE_RASTER_ROOT_SCALING.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/745c38db6468
Force WR picture tasks to fit into max target size r=Bert

Comment 6

[Andrei Ciure[:aciure]]

https://hg.mozilla.org/mozilla-central/rev/745c38db6468

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:kvark, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Comment 8

[Dzmitry Malyshau [:kvark]]

Comment on attachment 9138191 [details]
Force WR picture tasks to fit into max target size

Beta/Release Uplift Approval Request

• User impact if declined: Some websites may cause a GPU process crash
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The updated logic doesn't touch much of the other code than the one that was at fault.
• String changes made/needed:

Comment 9

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9138191 [details]
Force WR picture tasks to fit into max target size

Avoid a GPU crash. Approved for 76.0b3.

Comment 10

[Daniel Varga [:dvarga]]

https://hg.mozilla.org/releases/mozilla-beta/rev/65c3a3bb7460

Comment 11

[Catalin Sasca, Desktop Test Engineering [:csasca]]

Tried reproducing the issue on Firefox 76.0a1 (2020-04-01) on macOS 10.15 using the STR from Comment 0. While zooming the page, an intermittent crash occured "Signature: webrender::renderer::Renderer::draw_frame" and its two bug ID's (1583116 and 1624817). This crash happened on 76.0b2 as well.

It seems that 77.0a1 (2020-04-12) and 76.0b4 (where the fix for this issue is implemented) the crash is no longer reproducible.

Tried verifying with latest builds on Ubuntu 18.04 and Windows 10 without success as webrender was unusable on the two. Ubuntu just refused to change to webrender, and for Windows 10, after trying to zoom, the whole browser flashes two times, and about:support's composition will change from "webrender" to "basic". I was trying on two different systems which include an Intel HD Graphics (Ironlake) and on another with Intel HD530 graphics with latest drivers.

Kvark, any idea about these?

Comment 12

[Dzmitry Malyshau [:kvark]]

Chatted about this on Slack. The GPU crashes Catalin sees may be related, but they aren't observable on latest Beta, so I think we are fine to leave the patch in.

Comment 13

[Catalin Sasca, Desktop Test Engineering [:csasca]]

Successfully reproduced the issue on a 4k screen on Nightly 76.0a1 (2020-04-01) following only the steps from Comment 0.

The issue is no longer reproducible on latest Nightly 77.0a1 (2020-04-13) and 76.0b4. Thanks Kvark for helping out!