1489902 - [Wayland] Opengl/Webrender hangs in eglSwapBuffers()

Status: RESOLVED FIXED

(Core :: Graphics, defect, P2)

Description

[Robert Mader [:rmader]]

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0
Build ID: 20180904093908

Steps to reproduce:

Note: this is not a duplicate of bug 1480755. WebGL works fine/smooth again and both tested versions have the fix.

Enable accelerated layers (or webrender) on firefox-wayland 62 or flatpak nightly (in gnome wayland session).

Fedora 28, mesa 18.1.3, intel ivybridge


Actual results:

Flatpak nightly always hangs after the message "Attempting load of libEGL.so"

Ff 62 also hangs on first try ("Attempting load of libEGL.so"). After closing and trying again, sometimes it starts with the message:

Attempting load of libEGL.so
WebGL(0x7fb76bcd1000)::ForceLoseContext
WebGL(0x7fb76bcd1800)::ForceLoseContext


Expected results:

It should properly start in both cases

Comment 1

[Robert Mader [:rmader]]

This is got solved for me on recent versions of nightly (flatpak 64)
Still see it in fedora 29, firefox-wayland 62, though.

Comment 2

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

Yes, I can see that. It's frozen in Compositor thread, there's a backtrace:

#0  0x00007ffff7b603d1 in poll () at /lib64/libc.so.6
#1  0x00007ffff66c1b79 in poll (__timeout=-1, __nfds=1, __fds=0x7fffd18b7780) at /usr/include/bits/poll2.h:46
#2  0x00007ffff66c1b79 in wl_display_poll (display=display@entry=0x7ffff7868300, events=events@entry=1) at src/wayland-client.c:1710
#3  0x00007ffff66c35fc in wl_display_dispatch_queue (display=0x7ffff7868300, queue=0x7fffd01daa00) at src/wayland-client.c:1783
#4  0x00007fffce03510b in dri2_wl_swap_buffers_with_damage (drv=<optimized out>, disp=0x7fffd0120000, draw=0x7fffd01dc000, rects=0x0, n_rects=0) at drivers/dri2/platform_wayland.c:943
#5  0x00007fffce025df6 in eglSwapBuffers (dpy=0x7fffd0120000, surface=<optimized out>) at main/eglapi.c:1261
#6  0x00007fffeba323e8 in mozilla::gl::GLLibraryEGL::fSwapBuffers(void*, void*) const (this=0x7fffd0dfe7a0, dpy=0x7fffd0120000, surface=0x7fffd01dc000)
    at /home/komat/tmp676-trunk-gtk3/src-wayland/gfx/gl/GLLibraryEGL.h:227
#7  0x00007fffeba1fc9b in mozilla::gl::GLContextEGL::SwapBuffers() (this=0x7fffcd261000) at /home/komat/tmp676-trunk-gtk3/src-wayland/gfx/gl/GLContextProviderEGL.cpp:506
#8  0x00007fffebb08d46 in mozilla::layers::CompositorOGL::EndFrame() (this=0x7ffff78bde70) at /home/komat/tmp676-trunk-gtk3/src-wayland/gfx/layers/opengl/CompositorOGL.cpp:1840
#9  0x00007fffebcde602 in mozilla::layers::LayerManagerComposite::Render(mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&, mozilla::gfx::IntRegionTyped<mozilla::gfx::UnknownUnits> const&) (this=0x7fffcd2a8350, aInvalidRegion=..., aOpaqueRegion=...) at /home/komat/tmp676-trunk-gtk3/src-wayland/gfx/layers/composite/LayerManagerComposite.cpp:1007
#10 0x00007fffebcdd6c3 in mozilla::layers::LayerManagerComposite::UpdateAndRender() (this=0x7fffcd2a8350)
    at /home/komat/tmp676-trunk-gtk3/src-wayland/gfx/layers/composite/LayerManagerComposite.cpp:544
#11 0x00007fffebcdd232 in mozilla::layers::LayerManagerComposite::EndTransaction(mozilla::TimeStamp const&, mozilla::layers::LayerManager::EndTransactionFlags)
    (this=0x7fffcd2a8350, aTimeStamp=..., aFlags=mozilla::layers::LayerManager::END_DEFAULT) at /home/komat/tmp676-trunk-gtk3/src-wayland/gfx/layers/composite/LayerManagerComposite.cpp:465
#12 0x00007fffebd0c140 in mozilla::layers::CompositorBridgeParent::CompositeToTarget(mozilla::gfx::DrawTarget*, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const*)
    (this=0x7fffd174cc00, aTarget=0x0, aRect=0x0) at /home/komat/tmp676-trunk-gtk3/src-wayland/gfx/layers/ipc/CompositorBridgeParent.cpp:1105

Comment 3

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

dri2_wl_swap_buffers_with_damage() waits in frame throttling - we had this issue before and set SwapInterval to 0 was a workaround for it. I need to find the related info but AFAIK it's a bug in our wl_surface handling code.

Comment 4

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

It's documented at https://bugs.freedesktop.org/show_bug.cgi?id=106753

Comment 5

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

https://bugs.freedesktop.org/show_bug.cgi?id=106753#c6 is the resolution here - I'll investigate what changed because Firefox 63 starts fine but latest trunk fails.

Comment 6

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

The frame callback we use to check the parent surface commit is not enough. We need to listen frame callback on the parent surface as we don't have access to "committed" signal which is used by GdkWaylandWindow internally.

Comment 7

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

https://treeherder.mozilla.org/#/jobs?repo=try&revision=2a64808c65283ccd5181c99fa2b728a5cca86695

Comment 8

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

Attachment: Bug 1489902 - [Wayland/OpenGL] Don't draw to wl_surface owned by GtkWidget (mozcontainer) until it's commited, r=jhorak

Use frame callback to determine if we can draw to wl_surface owned by GtkWidget and use it as a base for EGL Window.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c6467f04bcd9
[Wayland/OpenGL] Don't draw to wl_surface owned by GtkWidget (mozcontainer) until it's commited, r=jhorak

Comment 10

[Natalia Csoregi [:nataliaCs]]

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

Comment 11

[Francois Guerraz]

I can see an improvement, a window is drawn but it's empty and transparent (just the title bar and frame are visible). Is it a known other bug or should I open one?

(fresh profile, just enabled gfx.webrender.all)

Comment 12

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

(In reply to Francois Guerraz from comment #11)
> I can see an improvement, a window is drawn but it's empty and transparent
> (just the title bar and frame are visible). Is it a known other bug or
> should I open one?
> 
> (fresh profile, just enabled gfx.webrender.all)

Please file a new one.