1679681 - Random pixel artifacts with AMD R600 shader backend (RS880)

Status: RESOLVED WORKSFORME

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

Description

[Kestrel]

Attachment: Random pixel artifacts on tab thumbnails

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.

Comment 1

[Kestrel]

Attachment: 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.

Comment 2

[Darkspirit]

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

Comment 3

[Kestrel]

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

Comment 4

[Andrew Osmond [:aosmond] (he/him)]

We are already blocking this GPU series on Linux.

Comment 5

[Jeff Muizelaar [:jrmuizel]]

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

Comment 6

[Kestrel]

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.

Comment 7

[Glenn Watson [:gw]]

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?

Comment 8

[Kestrel]

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.

Comment 9

[Matt Woodrow (:mattwoodrow)]

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.

Comment 10

[Kestrel]

Another user with what appears to be the same issue:

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

Comment 11

[Kestrel]

Two more reports here:

https://www.reddit.com/r/firefox/comments/ltfvw1/firefox_shows_these_colours_it_used_to_show_those/

Comment 12

[Kestrel]

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