User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0

Steps to reproduce:

In nightly-77.0a1.20200413:

• enable wayland, hardware acceleration & WebRenderer
• turn on widget.wayland-dmabuf-webgl.enabled
• open any page with WebGL (WebGL aquarium, GMaps, ...)

Actual results:

• WebGL context is lost (logged in both console and terminal)
• scene is not rendered

System Info:

OS: Linux 5.6.7-arch1-1
Compositing: WebRender
Window Protocol: wayland/drm
Desktop Environment: gnome
GPU: Mesa Intel(R) HD Graphics 630 (KBL GT2)
Driver Vendor: mesa/iris
Driver Version: 20.0.5.0

Important Flags:

layers.acceleration.force-enabled: true
gfx.webrender.all: true
gfx.webrender.enabled: true
widget.wayland-dmabuf-vaapi.enabled: true
widget.wayland-dmabuf-webgl.enabled: true

Just to be sure: does that issue persist on current nightly? You mention 20200413 and the about support shows 20200420 - we are at 20200430 now.

Sorry for the confusion, when I filed the report I was indeed on 20200420. I just tested it with a clean profile on 20200430 and the issue persists.

Also, WebGL works fine without dmabuf.

Could you try to find/confirm a regression range?

$ pip3 install --upgrade mozregression
$ GDK_BACKEND=wayland mozregression --good 2020-04-15 --bad 2020-04-30 --pref gfx.webrender.all:true widget.wayland-dmabuf-webgl.enabled:true -a https://webglsamples.org/aquarium/aquarium.html

If needed, you could try out dates directly:

$ GDK_BACKEND=wayland mozregression --launch 2020-03-20 --pref gfx.webrender.all:true widget.wayland-dmabuf-webgl.enabled:true -a https://webglsamples.org/aquarium/aquarium.html

I actually had to go way back to January to find the regression.

My first run resulted in:

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=7dea6cf71ca7fcc44923bcc26cac7d547a076c6f&tochange=5859680e3d7002fa18d9474e8d9c2dc083eb68a3

5859680e3d7002fa18d9474e8d9c2dc083eb68a3	Martin Stransky — Bug 1618367 [Wayland] Make nsWaylandDisplay usable on child processes, rename dmabuf preferences, r=jhorak

Since the flag had been renamed at some point I ran it again:

GDK_BACKEND=wayland mozregression --good 2020-01-01 --bad 2020-04-30 --pref layers.acceleration.force-enabled:true gfx.webrender.all:true widget.wayland-dmabuf-webgl.enabled:true widget.wayland_dmabuf_webgl.enabled:true -a https://webglsamples.org/aquarium/aquarium.html

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=76ee012b6099f1b2d4095d9d57c2e41f7a7c5a2c&tochange=4f788224c8d27a311f9f5620344f963b223bcb58

4f788224c8d27a311f9f5620344f963b223bcb58	Martin Stransky — Bug 1586696 [Wayland] Use wayland dmabuf as WebGL backend, r=jgilbert

Which narrowed it down to this very early commit!

So DMABUF WebGL never worked for you.
(In reply to yleretaille from comment #1)

Rejected System Calls
#: 0
Seconds Ago: 24366.228
PID: 75970
TID: 81401
Process Type: content
Syscall: 302
Arguments: 0
15
0x7f18c5bfe2a0
0
0
0x7f18a0600000

Does it work with disabled sandbox? (insecure)
$ GDK_BACKEND=wayland mozregression --launch 2020-04-29 --pref gfx.webrender.all:true widget.wayland-dmabuf-webgl.enabled:true security.sandbox.content.level:0 -a https://webglsamples.org/aquarium/aquarium.html

I just tried and disabling the sandbox does not make a difference.

Does it work with i965? $ MESA_LOADER_DRIVER_OVERRIDE=i965 GDK_BACKEND=wayland mozregression --launch 2020-04-29 --pref gfx.webrender.all:true widget.wayland-dmabuf-webgl.enabled:true security.sandbox.content.level:0 -a https://webglsamples.org/aquarium/aquarium.html

I wonder if it could have something to do with the drm format selection? This seems to have caused issues in quite a few places, esp. with the mesa-iris driver:
gnome - Add wl_shm support for 10 bpc formats and wl_shm/DMA-BUF support for 16 bpc half float formats
mesa - egl/wayland: Fix zwp_linux_dmabuf usage
(both committed fixes that are not released yet)

Example of how this causes issues with applications (mpv):
mpv - mpv ignores whether a dma-buf format is advertised or not
gnome - DRM_FORMAT_XRGB2101010 dma buffer format is not handled causing mpv failure on Wayland with Iris Mesa's driver

(In reply to Jan Andre Ikenmeyer [:darkspirit] from comment #10)

Does it work with i965? $ MESA_LOADER_DRIVER_OVERRIDE=i965 GDK_BACKEND=wayland mozregression --launch 2020-04-29 --pref gfx.webrender.all:true widget.wayland-dmabuf-webgl.enabled:true security.sandbox.content.level:0 -a https://webglsamples.org/aquarium/aquarium.html

I had the same idea and unfortunately that did not help.

(In reply to yleretaille from comment #11)

I wonder if it could have something to do with the drm format selection? This seems to have caused issues in quite a few places, esp. with the mesa-iris driver:
[...]
mesa - egl/wayland: Fix zwp_linux_dmabuf usage
(both committed fixes that are not released yet)
[...]

Just tried the newest mesa from master (mesa-git-20.2.0_devel.123196.f8424d3b999-1-x86_64), that did not help...

Could you try Mesa 19 for comparison? (On Debian Testing I have Mesa 19.3.3.) https://git.archlinux.org/svntogit/packages.git/log/trunk?h=packages/mesa

(In reply to Jan Andre Ikenmeyer [:darkspirit] from comment #14)

Could you try Mesa 19 for comparison?

I did some regression testing by downgrading mesa to various versions and I can now confirm that
mesa<=20.0.4 = good
mesa>=20.0.5 = bad

I will try to do some more testing to pinpoint it more precisely but that's a lot of changes to cover....

Okay, this way slightly annoying because mesa development follows llvm development and they switched from llvm 9.0 to 10.0 between 20.0.4 and 20.0.5 but ultimately I just had to let makepkg run in the background multiple times while working on other things.
Here are the results:

9de8d58a <--- 20.0.4 (GOOD)
ce2921a9
4c2c6e61
800e0245
c9f40581
e594e7fa
a93c67d6
3744a31d
04067fbe
49a4ba5e
1cf4f626
87f1e7b1
a0e857c7
820c636a
fbef99b5
053e5a2c
7f8b89e0
== 143c99ef == 2. TRY == RESULT: GOOD
8afe0611
e70e9d4e
3d5d4ee8
1fdf4255
de3d7dbe
d4ef9d6a
d15f45ca
26dfb62c
== abdb320a == 3. TRY == RESULT: GOOD
019bb880
2de66086
167e4344
9a0e6d64
== e0368798 == 4. TRY == RESULT: GOOD
== 4bf1d033 == 7. ADD == RESULT: GOOD
== 01bd0481 == 5. TRY == RESULT: iris: BAD, i965: GOOD
b5a8a2ae
== 13a79c15 == 1. TRY == RESULT: iris: BAD, i965: GOOD
== 6ae8c93b == 6. ADD == RESULT: BAD
8d1baa28
8980c580
9d50c53e
78a1deb9
5cbe7315
b637994b
7f2539dc
2111ccfb
3323a302
38e0d199
c71cf856 <--- llvm 10 support added
8be0ceb1
721648e2
8e811057
88f89f7a
fc140276
b5b56d89
01844f40
b1f08796
2f5509c4
ded9c5c4
d13c6c25
c447fcbc
feb2f12d
5cd2b945
9d052b25
76dbcb1f
5ef9dccf
29200718
eb39c5fb
5bbf4cc5
e16cb98c
4dfb9d9f
cb07bd31
728cf663 <--- 20.0.5 (BAD)

This points us to a series of changes by the same author which were added about 2 weeks ago:

4bf1d033  iris: properly free resources on BO allocation failure
01bd0481* iris: share buffer managers accross screens
b5a8a2ae  iris: make resources take a ref on the screen object
13a79c15  i965: store DRM fd on intel_screen
6ae8c93b* i965: share buffer managers across screens

The specific commits that broke dmabuf are 01bd0481 for iris and 6ae8c93b for i965, which implement sharing of buffer managers across screens. I don't know if the bug is in firefox or mesa though.

I also wanted to say that during testing i switched dmabuf on and off many times to confirm the behavior and it really does almost double the framerate, thanks for the great work!

link to corresponding mesa issue

Thank you so much for narrowing this down and filing an upstream bug! :)
(If they want to have anything be changed in Firefox, they should not hesitate to comment here. Thanks!)

(In reply to Jan Andre Ikenmeyer [:darkspirit] from comment #18)

Thank you so much for narrowing this down and filing an upstream bug! :)
And thanks to you for pointing me the right way :)

Happy to confirm that @llandwerlin's newest mesa merge request fixes the issue!

We need some kind of fallback here to test dmabuf and then fallback to EGL images.

The severity field is not set for this bug.
:jbonisteel, could you have a look please?

For more information, please visit auto_nag documentation.