Closed Bug 1677757 Opened 4 years ago Closed 4 years ago

Resizing GPU cache with glBlitFramebuffer causes rendering errors on Mali-T

Categories

(Core :: Graphics: WebRender, defect)

Unspecified
Android
defect

Tracking

()

RESOLVED FIXED
85 Branch
Tracking Status
firefox-esr78 --- unaffected
firefox83 --- disabled
firefox84 --- disabled
firefox85 --- fixed

People

(Reporter: jnicol, Assigned: jnicol)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file)

In bug 1669494 I switched to using glBlitFramebuffer rather than glCopyImageSubData on Mali when blitting between textures, due to performance reasons. I then noticed rendering issues on Mali-Gxx (bug 1669960), so reverted the change for Mali-Gxx, but kept it for Mali Txxx.

Now I've been testing a bit more, I see the same issue on Mali-Txxx.

In bug 1669960, I guessed this occurred when resizing picture cache textures. However, we no longer resize the picture cache, and the issue persists. The problem is actually when resizing the GPU cache texture. This texture is RGBAF32 format, and we use GL_LINEAR for the filter parameter to glBlitFramebuffer. The filter shouldn't really matter, as there is no scale involved in the blit. However, lots of the values after the blit are slightly off, eg 0.0 vs 0.00078125, so it appears the Mali driver is incorrectly doing some filtering. Switching to GL_NEAREST seems to fix the issue.

As an aside, in bug 1661528 we introduced a new texture upload path for Mali-G which requires copying between textures. Using glCopyImageSubData caused the driver to hang indefinitely some of the time, so we needed to use glBlitFramebuffer. However, due to this bug, we had to use glCopyImageSubData for different copies elsewhere. Fixing this bug seems like a good opportunity to simplify that decision: we can now always use glBlitFramebuffer on Mali (with GL_NEAREST filter). We should use a helper function that chooses between the 2 options based on the platform capabilities.

RGBA32bit is not even required to be filterable, so I can understand Mali's confusion :)
Looking forward for the patch that switches it to NEAREST.

Set release status flags based on info from the regressing bug 1669494

Using GL_LINEAR was causing incorrect filtering to occur when copying
the RGBAF32 GPU cache texture on Mali, causing rendering
errors. Switching to GL_NEAREST fixes it.

This is the same bug as bug 1669960, which was believed at the time to
only affect Mali-Gxx. On further testing the bug affects Mali-Txxx
too. Bug 1669960 was worked around at the time by using
glCopyImageSubData instead of glBlitFramebuffer. However, we want to
avoid using glCopyImageSubData on Mali: on Mali-T due to performance
reasons, and on Mali-G due to indefinite hangs. Fixing this filtering
bug allows us to switch both sets of devices to always use
glBlitFramebuffer.

Pushed by jnicol@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/9492c01a118b Use GL_NEAREST filter when copying texture data with glBlitFramebuffer. r=kvark
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 85 Branch
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: