GNOME Bugzilla – Bug 755675
GL: UI freezes when the window has a GtkHeaderBar and runs on top of X11 with AMD graphics
Last modified: 2015-11-30 15:31:08 UTC
Created attachment 312216 [details] Python implementation I've a problem with gtkglsink in my app, which uses a GtkHeaderBar as its titlebar. Under Wayland it works as it should, but under X11 the UI is in a weird state: it doesn't load the video (the sound plays, and if you unfocus and refocus the window a frame is displayed) and it doesn't change visual for states in widgets (like hovering), although they're responsive (respond to clicks, for example). If you remove the HeaderBar from the code, the video works as expected. In the attachment, you can see a simple Python code that triggers the issue on my computer. I've talked with some people on the irc channel and we came to the conclusion that it may be related to my video driver/card: Gallium 0.4 on AMD PALM (DRM 2.43.0, LLVM 3.7.0).
I'm inclined to say this is probably a gtk bug relating to its usage of multiple contexts. Do the gtk+ gl examples work if you add a headerbar to them?
Could you also provide a debug log with GST_DEBUG=gl*:7,gtk*:7,3 and backtrace a few seconds in of the headerbar case where the UI freezes. FWIW, Nouveau segfaults in the Headerbar case (multiple contexts issue that's been around for ever. It also freezes waiting on the glFence object which is probably the same issue. I'm suspecting the AMD case is that there is no synchronisation/missing bindTexture/etc in gtk between the GLArea and the window system contexts so the display is getting the texture before its been rendered to.
(In reply to Matthew Waters from comment #1) > Do the gtk+ gl examples work if you add a headerbar to them? I'm not sure about what you mean, but my current code uses a glimagesink with a GtkHeaderBar and everything works fine [in X11]. > Could you also provide a debug log with GST_DEBUG=gl*:7,gtk*:7,3 and backtrace a few seconds in of the headerbar case where the UI freezes. I'm adding the log as an attachment.
Created attachment 312234 [details] Debug log
(In reply to Ian from comment #3) > (In reply to Matthew Waters from comment #1) > > Do the gtk+ gl examples work if you add a headerbar to them? > > I'm not sure about what you mean, but my current code uses a glimagesink > with a GtkHeaderBar and everything works fine [in X11]. In the gtk source directory there are some examples for their GL stuff. 1. Do they all work? 2. Do they still work with a HeaderBar? > > Could you also provide a debug log with GST_DEBUG=gl*:7,gtk*:7,3 and backtrace a few seconds in of the headerbar case where the UI freezes. > I'm adding the log as an attachment. Nothing pops out as inconsistent. It's not waiting indefinitely on a fence object like nouveau so that's out. Some other data points that would be helpful if you could provide them. 1. Does running with LIBGL_ALWAYS_SOFTWARE=1 make it work? 2. Providing an apitrace trace of the execution on your AMD card. See https://github.com/apitrace/apitrace/blob/master/docs/USAGE.markdown for usage details. apitrace trace python3 file.py should work fine. 3. Attempt to re-run the trace and see if the correct output is displayed.
(In reply to Matthew Waters from comment #5) > In the gtk source directory there are some examples for their GL stuff. I couldn't find this directory you're talking about, and couldn't find any Python example on the internet, sorry. The example in gtk3-demo works fine, though, but I wasn't able to compile it from the provided source because I don't know how to C. :/ > 1. Does running with LIBGL_ALWAYS_SOFTWARE=1 make it work? No, but it now displays the 1st frame, instead of a black screen. > 2. Providing an apitrace trace of the execution on your AMD card. See > https://github.com/apitrace/apitrace/blob/master/docs/USAGE.markdown for > usage details. apitrace trace python3 file.py should work fine. > 3. Attempt to re-run the trace and see if the correct output is displayed. Well, the output was the same every time I ran it. I'll add the log as an attachment. The *.trace files are big (70-80Mb each), could you tell me what would be the best way to send it to you?
(In reply to Ian from comment #6) > (In reply to Matthew Waters from comment #5) > > In the gtk source directory there are some examples for their GL stuff. > > I couldn't find this directory you're talking about, and couldn't find any > Python example on the internet, sorry. The example in gtk3-demo works fine, > though, but I wasn't able to compile it from the provided source because I > don't know how to C. :/ Ok, so for example for for gdkgears, edit https://git.gnome.org/browse/gtk+/tree/tests/gdkgears.c#n117 to add the header bar. Them execute "make" to build, then attempt to run the gdkgears program and see if the problem exists there. You can attempt to do the same to the gtk3-demo example. The steps are the same. Edit https://git.gnome.org/browse/gtk+/tree/demos/gtk-demo/glarea.c#n374. make. Then attempt to run the gtk3-demo GL example. > > 1. Does running with LIBGL_ALWAYS_SOFTWARE=1 make it work? > > No, but it now displays the 1st frame, instead of a black screen. That's weird. It works fine here. What are your Mesa, X11, libdrm, kernel, etc versions? > > 2. Providing an apitrace trace of the execution on your AMD card. See > > https://github.com/apitrace/apitrace/blob/master/docs/USAGE.markdown for > > usage details. apitrace trace python3 file.py should work fine. > > 3. Attempt to re-run the trace and see if the correct output is displayed. > > Well, the output was the same every time I ran it. I'll add the log as an > attachment. The *.trace files are big (70-80Mb each), could you tell me what > would be the best way to send it to you? Either a file sharing service somewhere or just the first 50 or so frames should be sufficient to have a look and should fit under the 1600K attachment limit on bugzilla with compression (gzip, lzma, etc)? Running head -n<a number> file.trace > truncate.trace will truncate the trace to <a number> function calls. As a start, try <a number> = 5000.
(In reply to Matthew Waters from comment #7) > Ok, so for example for for gdkgears, edit > https://git.gnome.org/browse/gtk+/tree/tests/gdkgears.c#n117 to add the > header bar. Them execute "make" to build, then attempt to run the gdkgears > program and see if the problem exists there. You can attempt to do the same > to the gtk3-demo example. The steps are the same. Edit > https://git.gnome.org/browse/gtk+/tree/demos/gtk-demo/glarea.c#n374. make. > Then attempt to run the gtk3-demo GL example. So, I have news (don't know if bad or good yet): I just compiled and ran the gdkgears example and it doesn't work, the same problem as the video (the frames change only when the window is unfocused and then refocused). It was displaying a error when loading canberra (Gtk-Message: Failed to load module "canberra-gtk-module"), so I thought it would be easy, I ran it with "GTK_PATH=:/usr/lib/gtk-3.0" (the module is there), the message was gone, but nothing changed. Then I ran the gtk3-demo again and realized that it wasn't working! The sliders are unresponsive and I didn't think of moving it the first time I opened it (sorry, my fault!). Now we know this is a bug on the GTK side. Any suggestion of what should I do next? Open an issue targeting GTK+? > Either a file sharing service somewhere or just the first 50 or so frames > should be sufficient to have a look and should fit under the 1600K > attachment limit on bugzilla with compression (gzip, lzma, etc)? Here are all the files, if you still want to take a look: https://www.dropbox.com/sh/ut246u2ik58a85c/AADofnVMlLYjXEBV8N4nLpKma > Running head -n<a number> file.trace > truncate.trace will truncate the > trace to <a number> function calls. As a start, try <a number> = 5000. The files are binaries, so I was afraid of doing that...
Reassigning to gtk+
(In reply to Ian from comment #8) > Now we know this is a bug on the GTK side. Any suggestion of what should I > do next? Open an issue targeting GTK+? How do we know that ? Both gdkgears and the gtk3-demo example work just fine here, both under X and under wayland...
They do here as well. Apparently not under the AMD graphics card/Mesa he has though. I'm guessing you're on Intel. NVIDIA proprietary driver would also work as well. Nouveau segfaults as per usual with multiple contexts. I haven't got any AMD cards to test with. From what I've seen of stepping through the debugger, the Headerbar case goes through gdk_cairo_draw_from_gl() that doesn't happen without the HeaderBar. Of course it could be driver issues. For future reference the following is the information that GL gives us identify this card/sofware. GL_VERSION: 3.3 (Core Profile) Mesa 11.0.0 GL_SHADING_LANGUAGE_VERSION: 3.30 GL_VENDOR: X.Org GL_RENDERER: Gallium 0.4 on AMD PALM (DRM 2.43.0, LLVM 3.7.0)
(In reply to Matthew Waters from comment #11) > From what I've seen of stepping through the debugger, the Headerbar case > goes through gdk_cairo_draw_from_gl() that doesn't happen without the > HeaderBar. GtkGLArea calls gdk_cairo_draw_from_gl() when rendering, so that's not exceedingly useful. The draw_from_gl() call has various rendering paths, so it would be helpful to understand which one is the cause of the observed issue. > Of course it could be driver issues. That's usually the case, if it cannot be reproduced by more than one driver. There's still the matter of understanding if it's something being triggered by a wrong assumption inside GTK or not.
(In reply to Matthias Clasen from comment #10) > How do we know that ? Both gdkgears and the gtk3-demo example work just fine > here, both under X and under wayland... Sorry, what I meant was that it is not gstreamer-specific, but is probably something that happens with GL + GTK (I'm a newbie here, so please correct me if I'm wrong). --- I just want to emphasize that this issue is not HeaderBar-only. The video plays well in SSDed windows *only if I don't add other widget in the window*. As soon as other widget (a button, a label, etc.) is added, it behaves exactly as it does with a HeaderBar.
I've now added a headerbar to gdkgears.
(In reply to Matthias Clasen from comment #14) > I've now added a headerbar to gdkgears. Same problem on X11. Still working fine on Wayland. --- Something I noticed: in this specific gdkgears example I have that message regarding canberra (Gtk-Message: Failed to load module "canberra-gtk-module"), as I said in comment #8. And then I run it with "GTK_PATH=:/usr/lib/gtk-3.0" and the message is gone. Under Wayland, though, no message is displayed.
Seems someone has already reported this to the Mesa people :) Following a discussion on IRC, the problem seems to be with using the front buffer as a render target which I noticed in the trace is being used. https://bugs.freedesktop.org/show_bug.cgi?id=91930
Thanks for the pointer!
*** Bug 758764 has been marked as a duplicate of this bug. ***