3D support not working in Firefox 41.0.1

cyberalex4life commented 9 years ago

The output looks like this: (process:13412): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed 2015-10-02 23:43:27: basic_code_modules.cc:70: ERROR: Module /usr/lib/libsystemd.so.0 could not be stored 2015-10-02 23:43:27: basic_code_modules.cc:70: ERROR: Module /usr/lib/firefox/components/libdbusservice.so could not be stored 2015-10-02 23:43:27: basic_code_modules.cc:70: ERROR: Module /usr/lib/firefox/components/libmozgnome.so could not be stored 2015-10-02 23:43:27: basic_code_modules.cc:70: ERROR: Module /usr/lib/firefox/browser/components/libbrowsercomps.so could not be stored libva info: VA-API version 0.38.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib/dri/i965_drv_video.so libva info: Found init function vaDriverInit_0_38 libva info: va_openDriver() returns 0 [VS] Software VDPAU backend library initialized libva info: VA-API version 0.38.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/lib/dri/i965_drv_video.so libva info: Found init function vaDriverInit_0_38 libva info: va_openDriver() returns 0 NOT SANDBOXED Vector smash protection is enabled. screenshot from 2015-10-02 23-41-55 With 3d support disabled: and fullscreen works nice

ghost commented 8 years ago

I'm having a similar problem, but I can't seem to figure out what the problem is.

Using Arch, with Firefox 40 and FPP 0.3.2 r37 everything was working fine. When I upgraded to Firefox 41 and FPP 0.3.2 r50 (and now with 0.3.3), I got audio but no video. Turning off 3D fixed the video issue, but on some websites the flash was now extremely choppy and CPU usage went way up.

Downgrading both Firefox and FPP to versions that perviously worked didn't fix the issue, so I was thinking it was something else that changed causing the issue. Looking at the packages that I updated at the same time as Firefox, I see that I went from MESA 10.6 to 11.0. (I haven't tried downgrading to 10.6 yet).

Is it possible the problem is something between FPP and MESA that is causing the issue?

cyberalex4life commented 8 years ago

I am on Manjaro, so yes I think the problem is related to Mesa. I also had to switch from "sna" to "uxa" to reduce the tearing on intel. I also disabled vsync in driconf and in freshwrapper.conf.

ghost commented 8 years ago

Alright, I just downgraded to Mesa 10.6 and everything is working properly while using Firefox 41 and FPP 0.3.3.

Something between FPP and Mesa 11 is the problem.

i-rinat commented 8 years ago

Indeed, with Mesa 11 plugin renders as black box. Surprisingly, wmode=direct works fine (link)

cyberalex4life commented 8 years ago

I downgraded too, everything is ok now

i-rinat commented 8 years ago

Git bisect points to the http://cgit.freedesktop.org/mesa/mesa/commit/?id=f15a7f3c6e1bb802ae8c2a29a2dc35ff530aea4d

i-rinat commented 8 years ago

PepperFlash issues a glTexImage2D() call with GL_BGRA format, but Mesa with the patch above only allows GL_RGBA format. Indeed, GLES2 spec talks about only GL_RGBA available, contrary to desktop OpenGL which usually supports everything. So with Mesa 11.0.2 (previous 11.0.1 shouldn't be affected) glTexImage2D() fails, therefore there is no image in 3d mode. On the other hand, there is a GL_EXT_texture_format_BGRA8888 extension, which is unconditionally supported by Mesa, and brings GL_BGRA support. So I can't tell whenever there is an introduced bug, or there was a bug, and patch fixed it.

Also using shader translator and desktop GL (configure with -DWITH_GLES2=0) should help.

ghost commented 8 years ago

I just tested and you are correct that 11.0.1 does work correctly. 11.0.2 is the update that is affected.

cyberalex4life commented 8 years ago

maybe there is a problem with packages in Arch (Manjaro). For example, although Octave binaries are present, they are not compiled with java support. This is why I usually have to compile it myself (which takes over 30 minutes)

i-rinat commented 8 years ago

Related fix was recently pushed to Mesa git: http://cgit.freedesktop.org/mesa/mesa/commit/?id=6ad9ebb073fc4ed245ef8e9db4479a52e818cb92

It could even get to the 11.0.3 release, I think.

ghost commented 8 years ago

Thanks for looking into this!

cyberalex4life commented 8 years ago

thanks :)

i-rinat commented 8 years ago

Eh... I wasn't the one who added the patch to the Mesa library. It turned out, there were an issue already, about Weston.

worldowner commented 8 years ago

I compiled latest git version a few minutes ago and it doesn't even show black box. $ cat .config/freshwrapper.conf enable_3d = 0 enable_hwdec = 1

Errors:

2015-10-10 18:40:45: basic_code_modules.cc:70: ERROR: Module /usr/lib/libsystemd.so.0 could not be stored 2015-10-10 18:40:45: basic_code_modules.cc:70: ERROR: Module /usr/lib/libnss_myhostname.so.2 could not be stored 2015-10-10 18:40:45: basic_code_modules.cc:70: ERROR: Module /usr/lib/firefox/components/libdbusservice.so could not be stored 2015-10-10 18:40:45: basic_code_modules.cc:70: ERROR: Module /usr/lib/firefox/components/libmozgnome.so could not be stored

!!! [Child][OnMaybeDequeueOne] Error: Channel closing: too late to send/recv, messages will be lost

!!! [Child][MessageChannel] Error: (msgtype=0x700007,name=PHttpChannel::Msg_Cancel) Channel closing: too late to send/recv, messages will be lost

!!! [Child][MessageChannel] Error: (msgtype=0x3A00E7,name=PContent::Msg_AsyncMessage) Channel closing: too late to send/recv, messages will be lost

!!! [Child][MessageChannel] Error: (msgtype=0x200044,name=PBrowser::Msg_delete) Channel closing: too late to send/recv, messages will be lost

!!! [Child][MessageChannel] Error: (msgtype=0x3A009B,name=PContent::Msg_ScriptError) Channel closing: too late to send/recv, messages will be lost

!!! [Child][OnMaybeDequeueOne] Error: Channel closing: too late to send/recv, messages will be lost

For what I remember intel driver has been upgraded in the meantime (currently I have xf86-video-intel 1:2.99.917+478+gdf72bc5-2)

i-rinat commented 8 years ago

@worldowner, you have plugin crashes. Could you collect a backtrace?

worldowner commented 8 years ago

Sure, just let me know how please (can be link to doc, I don't expect copy/paste solution).

worldowner commented 8 years ago

BTW. It doesn't work on mesa 11.0.3 either.

i-rinat commented 8 years ago

Sure, just let me know how please

Sure, here is the [link]. Also Ubuntu have apport installed by default, and it steals core files. And maybe systemd does that too, I'm not sure. Check /proc/sys/kernel/core_pattern file, it should contain "core" without any pipe (|) characters.

i-rinat commented 8 years ago

It doesn't work on mesa 11.0.3 either.

I've checked now, Mesa 11.0.3 fixes black box issue on my machine. But if you were talking about plugin crash, that's another issue, which unlikely to be solved by Mesa update. It's more likely some bug in freshwrapper itself.

worldowner commented 8 years ago

# cat /proc/sys/kernel/core_pattern
|/usr/lib/systemd/systemd-coredump %p %u %g %s %t %e

$ ulimit -c
unlimited

$ coredumpctl 
No coredumps found.

There is no coredump in directory from which I've run firefox. I saw those error messages before I had looked for coredump. Firefox itself doesn't crash if that matters.

i-rinat commented 8 years ago

Messages about broken channel appear in two cases. First is when plugin crashes — plugins are hosted in a separate process by plugin-container binary. Since plugins are dynamic libraries, bug can cause whole process to crash. In that case Firefox's main process senses other side gone. Second case is when plugin-container hangs for longer than 60 seconds. In that case Firefox forcefully terminates plugin-container.

Only first on those two generates core files. So I guess in your case plugin hangs.

i-rinat commented 8 years ago

There is a way to debug such lockups. First one needs to increase timeout by changing dom.ipc.plugins.timeoutSecs parameter on about:config page. Default value is 60 seconds, I usually set it to something like 3600-7200, one or two hours. When plugin hangs, one needs to attach to the plugin-container process by:

$ gdb --pid $(pidof plugin-container)

and then request backtrace of all threads: thread apply all bt.

At least that can give a hint about bug location.

i-rinat commented 8 years ago

Since issue was caused by a change in Mesa 11.0.2, and that new behavior was later fixed in 11.0.3 and Mesa's master branch, I can say that was a Mesa bug, not something freshwrapper should adapt to.

worldowner commented 8 years ago

Just to inform, my issues are gone afrer Arch Linux upgrade.

cyberalex4life commented 8 years ago

Mine too, after switching to Manjaro with XFCE and mesa 11.0.3

i-rinat / freshplayerplugin