1656505 - Glitches on ncase.me/trust with dmabug-webgl enabled

Status: RESOLVED FIXED

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

Description

[Robert Mader [:rmader]]

Using Firefox 79 from Fedora 32, a local build from yesterday and todays nightly.

How to reproduce:

• use the Wayland backend
• make sure widget.wayland-dmabuf-webgl.enabled or, in 80/81, widget.dmabuf-webgl.enabled is enabled
• go to https://ncase.me/trust/

Observed result:

• certain graphics do not show up or are wrong
• the issue goes away when disabling widget.[wayland-]dmabuf-webgl.enabled

Comment 1

[Robert Mader [:rmader]]

Attachment: about:support on nightly 81 (20200731094606)

Comment 2

[Robert Mader [:rmader]]

Attachment: Without glitches

Comment 3

[Robert Mader [:rmader]]

Attachment: glitches on 79

Comment 4

[Robert Mader [:rmader]]

Attachment: glitches on local build or official nightly

Comment 5

[Robert Mader [:rmader]]

Note: the X11/EGL backend is also affected with bug 1655026 / D84901 applied.

Comment 6

[Robert Mader [:rmader]]

Martin, I'm currently trying to debug this but there's one thing I don't understand. Each value of gNewSurfaceUID, even after made atomic, does get used twice - is that expected? Here's a debug print with the values for mUID and this:

DMABufSurface constr 1 0x7fab17aeaec0
DMABufSurface destr 1 0x7fab17aeaec0
DMABufSurface constr 2 0x7fab17aeaec0
DMABufSurface constr 1 0x7fc3b8e097a0
DMABufSurface constr 3 0x7fab184f3d90
DMABufSurface constr 2 0x7fc3b8e0b2f0
DMABufSurface constr 4 0x7fab184f4250
DMABufSurface destr 2 0x7fab17aeaec0
DMABufSurface constr 3 0x7fc3b8e0b550
DMABufSurface constr 5 0x7fab184f4d00
DMABufSurface destr 2 0x7fc3b8e097a0
DMABufSurface destr 3 0x7fab184f3d90
DMABufSurface constr 4 0x7fc3b8e09ec0
DMABufSurface constr 6 0x7fab184f4e30
DMABufSurface destr 4 0x7fab184f4250
DMABufSurface constr 5 0x7fc3b8e0a5e0
DMABufSurface destr 3 0x7fc3b8e0b2f0
DMABufSurface constr 7 0x7fab184f3ff0
DMABufSurface destr 5 0x7fab184f4d00
DMABufSurface constr 6 0x7fc3b8e092e0
DMABufSurface destr 4 0x7fc3b8e0b550
DMABufSurface constr 8 0x7fab2937d7b0
DMABufSurface destr 5 0x7fc3b8e09ec0
DMABufSurface destr 6 0x7fab184f4e30
DMABufSurface constr 7 0x7fc3b8e09ec0
DMABufSurface destr 6 0x7fc3b8e0a5e0
DMABufSurface constr 9 0x7fab2968e1b0
DMABufSurface destr 7 0x7fab184f3ff0
DMABufSurface constr 8 0x7fc3b8e0a5e0
DMABufSurface destr 7 0x7fc3b8e092e0
DMABufSurface constr 10 0x7fab2937dc70
DMABufSurface destr 8 0x7fab2937d7b0
DMABufSurface constr 9 0x7fc3b8e092e0
DMABufSurface constr 11 0x7fab0f6231b0
DMABufSurface destr 9 0x7fab2968e1b0
DMABufSurface constr 10 0x7fc3b8e0bb40
DMABufSurface destr 8 0x7fc3b8e09ec0
DMABufSurface destr 9 0x7fc3b8e0a5e0
...

Comment 7

[Robert Mader [:rmader]]

Actually no reason to block bug 1655026, the EGL backend is still experimental and buggy anyways.

Comment 8

[Robert Mader [:rmader]]

I updated the STR as on the landing page the problem is actually even more visible. Also, the root problem seems to have been there from the very beginning with DMABuf WebGL - I checked with mozregression and the only difference with more recent versions is that areas that previously appeared white are now black.

My current guess is that the site request multiple surfaces/textures but the DMABuf backend only ever provides one - and all the additional ones somehow just reference the "main" surface, creating an odd pattern.

Martin, I think this a central design bug and not just a small issue that I could fix - can you have a look?

Comment 9

[Martin Stránský [:stransky] (ni? me)]

Martin, I'm currently trying to debug this but there's one thing I don't understand. Each value of gNewSurfaceUID, even after made atomic, does get used twice - is that expected? Here's a debug print with the values for mUID and this.

Yes, that's expected. the UID is connected to actual piece of GPU memory which can be transferred across the processes and may be attached to more than one dmabuf surface object in different processes. Then you may see more surfaces with the same ID.

btw. I don't see the regression - it's the '3. One tournament' page', right? I'm on Intel GPU, Fedora 32 and latest Fedora build.

Comment 10

[Martin Stránský [:stransky] (ni? me)]

Ah great, I see it on latest nightly which is a good news. I'll look at it.

Comment 11

[Martin Stránský [:stransky] (ni? me)]

The game of trust is a great example. I can reproduce it even with Firefox 79. Looks like the frame buffer is used as a texture instead of the actual one.

Comment 12

[Martin Stránský [:stransky] (ni? me)]

Attachment: Bug 1656505 [Linux] Use correct RGB/RGBA formats with dmabuf, r?jhorak

Comment 13

[Martin Stránský [:stransky] (ni? me)]

Attachment: Bug 1656505 [Linux] Restore active texture when dmabuf texture is created and provide logging to dmabuf surfaces, r?jhorak

• Restore active texture when dmabuf texture is created at DMABufSurfaceRGBA::CreateTexture()/DMABufSurfaceYUV::CreateTexture.
• Provide more logging for DMABufSurfaceRGBA surfaces.
• Implement DMABufSurfaceRGBA::DumpToFile() to save dmabuf surface content to png file.

Depends on D88381

Comment 15

[Robert Mader [:rmader]]

Just tested and it appears to fix all the glitches I've encountered so for - great! Hope the patches can be uplifted to beta and maybe even the fedora stable version.

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c868a37827ec
[Linux] Use correct RGB/RGBA formats with dmabuf, r=jhorak
https://hg.mozilla.org/integration/autoland/rev/659a72c0d0e6
[Linux] Restore active texture when dmabuf texture is created and provide logging to dmabuf surfaces, r=jgilbert

Comment 17

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/c868a37827ec
https://hg.mozilla.org/mozilla-central/rev/659a72c0d0e6