Non-fullscreen flash does not render if radeon X driver uses glamor

[v-fox]

On my card, Radeon 6870/rv940, if glamor 2D acceleration is used instead of EXA then all non-fullscreen flash rendering is just not happening. With video players I can just put them in fullscreen mode and that's fine but any windowed flash instance repaints only if I minimize/maximize the browser.
I'm not sure if its freshplayerplugin's or glamor's fault but freshplayerplugin is the only rendering app that I've found doing that.

The only possible relevant log message I've seen is:

[fresh 10892] not implemented: PPB_OpenGLES2VertexArrayObject;1.0
[fresh 10892] not implemented: PPB_OpenGLES2DrawBuffers(Dev);1.0

[MALLER-LAGOON]

the same problem here, i have a radeon 5670

[thof]

I've encountered the same error but on Intel so it is rather freshplayerplugin related problem. In order to reproduce it just pick random video from http://sport.tvp.pl/wideo

[neufeind]

I experienced the same on Intel. Embedded in a webpage the controls of a video is shown but no picture, going to fullscreen the video plays fine. Example-video: https://media.ccc.de/browse/conferences/camp2015/camp2015-6926-satellite_open_ground_station_network.html

[i-rinat]

Still can't reproduce. I'm trying with modesetting driver on Intel GPU, and Xorg.0.log tells that GLAMOR is used.

[neufeind]

It doesn't mention anything about GLAMOR for me. Using an "Intel(R) HD Graphics 5500" here.

[neufeind]

Hmm, installed missing package "libva-intel-driver", rebootet ... and now can't reproduce it anymore. Even when removing that libva again I can't seem to get the error back. I'll report here again when I have a "testcase" (when it breaks) again.

[i-rinat]

@neufeind,
By the way, on a page you gave link to, HTML5 video is used, in WebM format. It only falls back to Flash when <video> is not supported by browser at all. I was curious, and finally managed to enable Flash-based player only after renaming video tag on the page itself.

[neufeind]

They had flash-video when I tried it. But since it's a live event, maybe they just added webm-video meanwhile. It's using WebM for me as well, at the moment.

[v-fox]

Still can't reproduce. I'm trying with modesetting driver on Intel GPU, and Xorg.0.log tells that GLAMOR is used.

Looks like open AMD drivers really don't like your work >_< Your va_gl and FPP's video decoding can crash fresh X and kernels and now this. I have no idea what goes wrong but all flash things (beside non-embedded Youtube flash player which strangely does show up) are consistently invisible in non-fullscreen under open AMD drivers with glamor, stable or bleeding edge.

[i-rinat]

beside non-embedded Youtube flash player

@v-fox, does adding enable_windowed_mode = 0 to ~/.config/freshwrapper.conf change anything?

[i-rinat]

Looks like open AMD drivers really don't like your work

I tend to use unusual code paths. "Normal" applications that use OpenGL, usually create a window, an OpenGL context, and start drawing and flipping. That works almost everywhere. But in this project I instead create a X Pixmap, attach OpenGL|ES2 context (but acquired through GLX, not EGL), draw, then copy data from that offscreen pixmap to either another X Pixmap, provided by browser, or to a X Window, which can also be owned by either browser, or by plugin. If there could be transparency involved, X drawables are alpha-blended with XRender. In fact, all copying between drawables now use XRender.

[v-fox]

@v-fox, does adding enable_windowed_mode = 0 to ~/.config/freshwrapper.conf change anything?

No. No noticeable difference.

I tend to use unusual code paths.

Heh, you sure do ! And it seems to expose inadequacies in untested driver code. So, please, if you have any idea about how it may fail, relay it to the freedesktop devs. Because I almost believed that days of hard crashes and screen corruption are over for open GPU drivers.

In fact, all copying between drawables now use XRender.

Isn't everything tends to move away from XRender ? I even read on Mozilla's Bugzilla among many how-to-render discussions that it's better to disable xrender in Firefox if it doesn't introduce problems on your machine.

[i-rinat]

Isn't everything tends to move away from XRender?

As I'm working on a middle-ware, I have to support specific APIs. NPAPI allows plugins to be transparent. Browser draws what it wanted to draw into a Pixmap, then pass it to the plugin, which draws over it. Everything is fine if plugin is aware of that procedure. But PPAPI plugins are not. They can either use PPB_Graphics2D and create BGRA images from scratch, or use PPB_Graphics3D and eventually draw the same BGRA images. Even if I create a context on top of browser-supplied pixmap, to acquire previously stores image, first glClear() call will wipe its content.

There are multiple solutions. One can (1) download data from a pixmap to CPU memory, make alpha-blending, and upload it to GPU again. Or (2) derive GL texture from that pixmap, derive texture from offscreen pixmap where PPB_Graphics3D draws to, and then in a separate context alpha-blend two textures, with eventual rendering to the pixmap. Or (3) to ask XRender to draw one pixmap on another with alpha-blending.

I tried all three techniques, in that exact order. So far, XRender-based solution is the most simple and the most CPU/GPU efficient.

By the way, cairo will use XRender anyway :-)

[i-rinat]

I don't think I can fix it.

[v-fox]

I don't think I can fix it.

I tried to raise awareness of X's developers and there is new, seriously improved release of X's stack but the problem unfortunately persists :( I may only ask you to approach them with details of your graphical manipulations and ask them what could be broken on their side.

[i-rinat]

to approach them with details of your graphical manipulations

Just reporting won't be enough. There needs to be active collaboration, which is not possible since I can't reproduce the issue on any of hardware available to me.

There have to one which can reproduce the issue and can find where bug really is. Hence "help wanted".

[v-fox]

There have to one which can reproduce the issue and can find where bug really is. Hence "help wanted".

Well, I would like to assist but I don't know where to look. I surmise that it may be radeon-specific ("Gallium 0.4 on AMD BARTS (DRM 2.43.0, LLVM 3.7.0)" of Mesa-11.0.5 for me) and AMD Mesa devs could figure this out... if they would try FPP out.

[i-rinat]

Say, I have an exact hardware and software versions which triggers the bug. Next step is to isolate failing code, to create a minimal working sample.

Since you have mentioned that enable_windowed_mode=0 makes no difference, it's worth to focus only on rendering to an X Pixmap. Rendering code is in handle_graphics_expose_event() function in np_functions.c file. There are three cases, one uses XPutImage(), while other two use XRenderComposite(). You need to determine which is used in your case (I use printfstatements for such debugging), and use that code as a starting point.

[v-fox]

I figured out what was wrong: it didn't like "skia" used as "azure" backend in gfx.canvas.azure.backends and gfx.content.azure.backends. With cairo it renders fine with kernel 4.4.3 & Mesa 11.1.2 now. BUT fullscreen flash is all-black and unresponsive (I have to kill it with xkill if I try to fullscreen anything). Maybe there are other, driver-level glitches too. After all, using flash's (both in FF via FPP and in Chromium) vaapi via shims, Gallium one or yours, completely kills GPU handling, even driver reset doesn't help. And that's a long-standing glitch that driver-makers are not in a hurry to fix.

[i-rinat]

With cairo it renders fine with kernel 4.4.3 & Mesa 11.1.2 now.

That's an interesting observation. Thank you for sharing.

that's a long-standing glitch that driver-makers are not in a hurry to fix.

I've seen that a lot: users suffering from bugs, which I can't reproduce and therefore can't investigate and fix. It could be they can't fix it for the similar reason.

[i-rinat]

Since November 2015 a way to disable XRender usage was added (in b07d480 and some previous commits). Try to add enable_xrender = 0 to ~/.config/freshwrapper.conf.

[v-fox]

I've seen that a lot: users suffering from bugs, which I can't reproduce and therefore can't investigate and fix. It could be they can't fix it for the similar reason.

They specifically said that don't pay attention to their in-Mesa vaapi-shim since it's more of a measure of desperation. "We only did the VA-API implementation as a drop in replacement when the user has no other choice than to use VA-API" © - in the link above. But such heavy, unrecoverable bugs are unacceptable.

Since November 2015 a way to disable XRender usage was added (in b07d480 and some previous commits). Try to add enable_xrender = 0 to ~/.config/freshwrapper.conf.

Changing freshwrapper.conf. settings (including enable_xrender) doesn't seem to be making difference but disabling gfx.xrender.enabled in FF returns the bug. Fullscreen is blacked-out either way.
In fact, this is what seem to made difference, I tried changing gfx.canvas.azure.backends again to "skia,cairo" while having gfx.xrender.enabled=1 and it worked. It's like it wants CairoUseXRender=1 in about:support.

[i-rinat]

They specifically said that don't pay attention to their in-Mesa vaapi-shim

That doesn't look like VA-API-related issue. Otherwise it would trigger in non-fullscreen mode too.

I've seen a similar bug once. With running compton in opengl vsync mode a simple app that created window of size 1366x768 resulted in graphics malfunctioning. As I remember, everything else continued to work, I just didn't have a way to see what happens. With 1365x768 it worked fine. There was something wrong with that exact geometry.

[v-fox]

That doesn't look like VA-API-related issue. Otherwise it would trigger in non-fullscreen mode too.

Yes. I was talking about VAAPI issue with which radeon GPU completely collapses if Flash (native PPAPI and via FPP) tries to use it or your libvdpau_va_gl is used anywhere.

There was something wrong with that exact geometry.

I use a setup of 3200x1080 virtual screen our of LCD 1920x1080 + CRT 1280x1024 where CRT is unplugged. In FPP settings I use
fullscreen_width = 1920
fullscreen_height = 1080
but putting zeroes doesn't change anything. It helped long ago when CRT was plugged and fullscreen issue was absent.