1590832 - [Wayland] Crash [@ radeonsi_dri.so@0xa15971 ] with dmabuf/sway - unmap

Status: RESOLVED FIXED

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

Description

[Johannes Pfrang [:johnp]]

Enabling dmabuf with Basic compositing (layers acceleration not force enabled and webrender force disabled) on Fedora 31 with sway crashes the browser immediately on startup:

bp-44973e52-de77-4e4a-9cc5-b26c60191023

Comment 1

[Johannes Pfrang [:johnp]]

Also crashes with OpenGL: bp-02c3b472-a17b-4587-a8ee-d90610191023
And Webrender: bp-191b5969-f68a-4915-859f-6a6ea0191023

Comment 2

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

It's the same - dmabuf unmap. Do you see anything in journalctl or dmesg? I wonder why the unmap fails.

Comment 3

[Johannes Pfrang [:johnp]]

Unfortunately nothing in either journal or dmesg.

Comment 4

[Johannes Pfrang [:johnp]]

Fwiw, I installing the debuginfo packages and running

# eu-addr2line --pretty-print -f -e /usr/lib64/dri/radeonsi_dri.so 0xa15971
tc_transfer_unmap at ../src/gallium/auxiliary/util/u_threaded_context.c:1588:7

gets us here. (mesa 19.2.1 from updates-testing due to Fedora 31 final freeze)

Comment 5

[Aidan Harris]

Is this fixed now? I used to be able to consistently reproduce this crash in both Sway and Weston (weirdly not in KDE's kwin or GNOME's mutter though) but can't any more.

I can see a bunch of the dmabuf preferences have changed though.

There are now preferences for:

• widget.wayland_dmabuf_textures.enabled
• widget.wayland_dmabuf_basic_compositor.enabled
• widget.wayland_dmabuf_webgl.enabled

I only have widget.wayland_dmabuf_backend.enabled set to true and with this there are no crashes. How can I tell if dmabuf is being used and should any of the other preferences be changed?

Comment 6

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

(In reply to Aidan Harris from comment #5)

Is this fixed now? I used to be able to consistently reproduce this crash in both Sway and Weston (weirdly not in KDE's kwin or GNOME's mutter though) but can't any more.

dmabuf is disabled by default and the preferences was also changed.

I can see a bunch of the dmabuf preferences have changed though.

There are now preferences for:

• widget.wayland_dmabuf_textures.enabled
• widget.wayland_dmabuf_basic_compositor.enabled
• widget.wayland_dmabuf_webgl.enabled

Yes, those are here for testing purposes only. WebGL may be the only useful application when Bug 1586696 lands.

I only have widget.wayland_dmabuf_backend.enabled set to true and with this there are no crashes. How can I tell if dmabuf is being used and should any of the other preferences be changed?

widget.wayland_dmabuf_backend.enabled was renamed to widget.wayland_dmabuf_textures.enabled to reflect its actual meaning.

Comment 7

[Aidan Harris]

Yes, those are here for testing purposes only. WebGL may be the only useful application when Bug 1586696 lands.

Thanks, I'll wait for that to land and report back if the crashes still happen.

Comment 8

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

Hi, can you try to enable dmabuf for WebGL (see https://bugzilla.mozilla.org/show_bug.cgi?id=1586696#c19) and test it on some WebGL scene if you still see the issue?
Thanks.

Comment 9

[Johannes Pfrang [:johnp]]

With latest nightly on F31 (sway 1.4, mesa 19.2.8, kernel 5.5.5, RX470) all WebGL scenes I tried to play with widget.wayland_dmabuf_webgl.enabled didn't display anything. Console output:

Modifiers specified, but DRI is too old
WebGL(0x7f8ccc84e800)::LoseContext(0)

Without the preference WebGL works fine.

Comment 10

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

(In reply to Johannes Pfrang [:johnp] from comment #9)

With latest nightly on F31 (sway 1.4, mesa 19.2.8, kernel 5.5.5, RX470) all WebGL scenes I tried to play with widget.wayland_dmabuf_webgl.enabled didn't display anything. Console output:

Modifiers specified, but DRI is too old
WebGL(0x7f8ccc84e800)::LoseContext(0)

Without the preference WebGL works fine.

I see, thanks. We'd need to figure out how to detect we can use the modifiers.

Comment 11

[Johannes Pfrang [:johnp]]

I also tested the preference on KDE Plasma Wayland, where it worked fine (apart from bug 1593478 and bug 1616894).

edit: Could sway erroring-out be due to wlroots dropping support for per-plane dma-buf modifiers?

Comment 12

[Val Packett]

Modifiers specified, but DRI is too old

Looks like WaylandDMABufSurfaceRGBA::Create already handles this by creating without modifiers if creating with modifiers failed.
(so changing useModifiers to false does not help.) Might be another issue there??

I get a bit more info after this:

JavaScript warning: , line 0: Error: WebGL warning: <PresentScreenBuffer>: screen->Resize failed. Losing context.
WebGL(0x823e4bb00)::LoseContext(0)
JavaScript warning: , line 0: Error: WebGL context was lost.

Comment 13

[Val Packett]

I am also getting a GBM unmap crash with dmabuf textures. In tc_transfer_unmap the transfer->resource (i.e. the address we're unmapping) ends up having a funky value 0xffacababffacabab.

And after https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2147 I'm getting a GPU reset with dmabuf webgl…

Comment 14

[Val Packett]

Attachment: Bug 1590832 - fix Wayland dmabuf texture crash and rendering on Radeon

The documentation of gbm_bo_unmap describes the second argument as
"map_data opaque ptr returned from prior gbm_bo_map",
which refers to the pointer written to the map_data location by gbm_bo_map,
not the pointer returned by gbm_bo_map.

This fixes crashes with widget.wayland-dmabuf-textures.enabled
on the Mesa RadeonSI driver.

Comment 15

[Val Packett]

Okay, how did this ever work? ^^ I guess on Intel, the map_data was equal to the returned value? It doesn't seem unused by Intel..

Also I totally see how the GBM documentation could be confusing.. "\return Address of the mapped buffer that should be unmapped with gbm_bo_unmap" that just reads like "pass this return value there". Nope, haha, it's the value "returned" via the map_data thing.

Comment 16

[Val Packett]

Also added mBufferModifier = DRM_FORMAT_MOD_INVALID; to the fallback code path so that eglCreateImageKHR no longer fails.
Now I can actually see rendering with dmabuf textures!! However it's glitchy and there's a lot of "Failed to create DrawTarget" messages on the console, but that's out of scope for this bug, I'm not sure if textures are even supposed to fully work already.

And dmabuf webgl works too! :) It is spamming "Modifiers specified, but DRI is too old" because of the first attempt (the non-fallback path) on the console.. maybe we should remember that it failed once and no longer attempt it.

Comment 17

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

I think Bug 1619530 is related.

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/bf8c2eefd9b2
fix Wayland dmabuf texture crash and rendering on Radeon r=stransky

Comment 19

[Oana Pop-Rus]

https://hg.mozilla.org/mozilla-central/rev/bf8c2eefd9b2