1719345 - Red lines appears in some webites (PowerVR Rogue 8320)

Status: RESOLVED FIXED

(Core :: Graphics, defect, P3)

Description

[Kevin Brosnan [Ex-Mozilla]]

From github: https://github.com/mozilla-mobile/fenix/issues/20137.

Steps to reproduce

Launch Fenix
Go to Github.com

Expected behavior

Website should look normal

Actual behavior

Device information

• Device vendor / model and Android version: Samsung A12 / Android 11
• Firefox for Android version: 89.1.1

Other Browsers Works fine like Vivaldi and Brave

Change performed by the Move to Bugzilla add-on.

Comment 1

[Brad Werth [:bradwerth]]

Jamie, can you take a look?

Comment 2

[Jamie Nicol [:jnicol]]

Attachment: about:support

Comment 3

[Jamie Nicol [:jnicol]]

I cannot reproduce on my Samsung A10s (compared to the reporter's Samsung A12). This also has a PowerVR GE8320, but is running Android 10, versus the reporter's 11, and a slightly different driver version.

My phone should hopefully get an update to android 11 in the coming weeks, and then I will hopefully be able to reproduce.

Comment 4

[Jamie Nicol [:jnicol]]

This has been a tricky one to debug, as even after updating to android 11 I could only reproduce very intermittently.

What is happening is that in one pass we render some elements (eg borders) to our RGBA8 texture atlases. Then in the next pass we attempt to render some clip masks to an R8 render target. For some reason these clip masks end up in the RGBA8 texture from the previous pass, potentially overwriting an image or border with some red shapes. Then when the picture cache tile is rendered we end up with red lines instead of borders, or red shapes instead of an image.

I am uncertain why this only occurs so infrequently. Reproducing in renderdoc did not help much, it just proved we are correctly binding the render targets, but the data ends up in the wrong place for some reason.

When playing around with the code, I did notice that by removing all clipping code from our shaders I can make it reproduce very reliably. Presumably the effect this has is that the clip mask texture will never be bound to a shader, as the clip mask sampler presumably gets optimized out. I also then noticed that by removing the glInvalidateFramebuffer call that occurs once we have finished using the clip mask later in the frame, it no longer reproduces. Perhaps glInvalidateFramebuffer is incorrectly discarding some memory too early, and the pending writes to the target therefore end up in the wrong place.

After reinstating the clipping code but still avoiding calling glInvalidateFramebuffer, I have been unable to reproduce the bug. However, due to its intermittent nature I cannot be 100% certain that fixes it. But it's certainly worth a try.

Comment 5

[Jamie Nicol [:jnicol]]

Attachment: Bug 1719345 - Don't invalidate render targets after use on PowerVR. r?#gfx-reviewers

On PowerVR devices we have seen reports of red lines and shapes
appearing randomly on the screen. What is happening is that clip masks
are being rendered in to the RGBA8 texture atlases that were the
previous pass' target, rather than the current R8 render target. Red
shapes therefore appear on top of the cached items in the RGBA texture
atlases, and parts of these subsequently get rendered to picture cache
tiles then the screen.

This appears to be due a bug with glInvalidateFramebuffer. We call
this function once we have finished using a render target for the
frame (ie we have rendered all items which need a clip mask). But
presumably, due to the asynchronicity of OpenGL, the draw calls to
render the clip masks to the render target are in fact still pending
at this point. Perhaps the driver incorrectly recycles the render
target's memory too early, and as a result the masks get written to
the wrong texture.

This patch therefore omits the calls to glInvalidateFramebuffer on
PowerVR devices. While this bug has been hard to reproduce reliably,
it appears to solve the issue.

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/bd3855f0c74c
Don't invalidate render targets after use on PowerVR. r=gfx-reviewers,jrmuizel

Comment 7

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/bd3855f0c74c

Comment 8

[Jamie Nicol [:jnicol]]

Comment on attachment 9235572 [details]
Bug 1719345 - Don't invalidate render targets after use on PowerVR. r?#gfx-reviewers

Beta/Release Uplift Approval Request

• User impact if declined: Users with PowerVR GPUs occasionally see random red shapes and lines appear on screen
• Is this code covered by automated tests?: Yes
• 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): Omits call to buggy driver function that doesn't have much effect anyway (it is an optimization on windows, but doesn't do much on mobile GPUs)
• String changes made/needed:

Comment 9

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9235572 [details]
Bug 1719345 - Don't invalidate render targets after use on PowerVR. r?#gfx-reviewers

Approved for Fenix 92.0.0-beta.3.

Comment 10

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/a63e0d99c5e2