Closed Bug 1679681 Opened 2 years ago Closed 2 years ago

Random pixel artifacts with AMD R600 shader backend (RS880)

Categories

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

Firefox 85
Unspecified
Linux
defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox-esr78 --- unaffected
firefox83 --- disabled
firefox84 --- disabled
firefox85 --- disabled
firefox86 --- disabled
firefox87 --- disabled
firefox88 --- fixed

People

(Reporter: ke5trel, Unassigned)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression)

Attachments

(2 files)

Incorrect color pixels have started appearing in the Ctrl+Tab switcher thumbnails with webrender enabled on device AMD RS880 (0x9715) (blocklisted) on Ubuntu 20.10 (X11 and Wayland). Each press causes the pixels to change position and sometimes color. The color within each thumbnail is the same, usually cyan/green/blue/black.

It does not occur with software webrender and I have not seen this kind of artifact anywhere else in the interface (see Comment 1).

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=762270e639cf76b91a06d99f4a0639e2b6192af3&tochange=4e6e7829d164521667c5df5b67ef0bbcabb139a0

Regressed by Bug 1673387.

Severity: -- → S4
Priority: -- → P3
Attached image PDF pixel artifacts

I just discovered that PDFs have the same pixel artifacts with the same regression range. The artifacts change position rapidly when scrolling like a noise effect.

Summary: Ctrl+Tab thumbnails have random pixel artifacts → PDFs and Ctrl+Tab thumbnails have random pixel artifacts

(Robert Mader [:rmader] from bug 1679755 comment 10)

TBH., to me this sounds like driver bugs. The r600 driver is AFAIK not in the best shape and as long as we don't get reports from radeonsi / some other driver users, I think the more appropriate place for this bug would be https://gitlab.freedesktop.org/mesa/mesa/-/issues

We could, however, think about blocklisting r600 for the WR rollout.

See Also: → 1679755
Summary: PDFs and Ctrl+Tab thumbnails have random pixel artifacts → PDFs and Ctrl+Tab thumbnails have random pixel artifacts (mesa/r600)

This is not limited to mesa/r600 as it also happens with mesa/kms_swrast driver.

See Also: 1679755
Summary: PDFs and Ctrl+Tab thumbnails have random pixel artifacts (mesa/r600) → PDFs and Ctrl+Tab thumbnails have random pixel artifacts (AMD RS880)

We are already blocking this GPU series on Linux.

See Also: → 1673939
Summary: PDFs and Ctrl+Tab thumbnails have random pixel artifacts (AMD RS880) → PDFs and Ctrl+Tab (canvas) thumbnails have random pixel artifacts (AMD RS880)

Do you see the problem when using mesa/kms_swrast with both softpipe and llvmpipe?

Flags: needinfo?(ke5trel)

Bug 1682365 has progressively caused artifacts to spread to the entire browser.

LIBGL_ALWAYS_SOFTWARE=true GALLIUM_DRIVER=softpipe — No artifacts but unbearably slow.
LIBGL_ALWAYS_SOFTWARE=true GALLIUM_DRIVER=llvmpipe — Crashes on startup.
LIBGL_DRI3_DISABLE=true — Uses llvmpipe but artifacts still occur.
R600_DEBUG=nosb — No artifacts.
R600_DEBUG=sbdry — No artifacts.

This seems to indicate the problem is in the shader backend optimized bytecode.

Flags: needinfo?(ke5trel)
Regressed by: 1682365

The crash you get on startup with LIBGL_ALWAYS_SOFTWARE=true GALLIUM_DRIVER=llvmpipe is interesting - that command line works fine for me. Is there any further information on the console about the crash?

I don't have a great understanding of exactly where mesa/kms_swrast fits into the graphics stack - but from what I understand, it would still be using the R600 driver code for surface allocation and presentation, even though the actual rasterization would be done on the CPU. Is that correct?

Flags: needinfo?(ke5trel)

Mesa updated recently from 20.2.1 to 20.2.6 and now about:support reports the driver as mesa/r600 instead of mesa/kms_swrast on Wayland. Software llvmpipe no longer crashes when starting, it does not have artifacts like the default configuration and performance is a little better than the R600_DEBUG=nosb workaround but it devours CPU when there is any change to the display.

I discovered the artifacts first appeared earlier in version 83 for WebGL content with EGL and this expanded to GLX in 85 beta with Bug 1673387. The WebGL artifacts do not occur at some zoom levels or if the frame's CSS is modified so that overflow is not hidden or a margin is added.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=e7fb0c8ea34ba4116a9f3ddaf4bb1d221ce490d4&tochange=c0f6b814ea1df7390b42aa9240b097619095c0a0

Regressed by Bug 1664804.

I don't see these artifacts in other applications, including glxgears, es2gears, glmark2, glmark2-es2, Chromium (with flags Accelerated 2D canvas, Override software rendering list, GPU rasterization, Zero-copy rasterizer) or GNOME itself.

Flags: needinfo?(ke5trel)
Regressed by: 1664804
Summary: PDFs and Ctrl+Tab (canvas) thumbnails have random pixel artifacts (AMD RS880) → Random pixel artifacts with AMD R600 shader backend (RS880)
Has Regression Range: --- → yes
Flags: needinfo?(matt.woodrow)
Blocks: wr-linux-amd-r600
No longer blocks: wr-linux

It looks like the only relevant change in that regression range is that we started tagging opaque WebGL surfaces with TextureFlags::IS_OPAQUE.

I don't think that's an interesting functional change, but might have exposed an existing driver bug.

Flags: needinfo?(matt.woodrow)

Another user with what appears to be the same issue:

https://www.reddit.com/r/firefox/comments/les797/green_pixels_when_viewing_pdf/

The artifacts no longer appear anywhere in the browser, PDFs or WebGL after Bug 1694909.

Status: NEW → RESOLVED
Closed: 2 years ago
Depends on: 1694909
Resolution: --- → WORKSFORME
See Also: → 1695495
You need to log in before you can comment on or make changes to this bug.