1684194 - Use RenderCompositorEGL on X11/EGL

Status: RESOLVED FIXED

(Core :: Graphics: WebRender, enhancement)

Description

[Sotaro Ikeda [:sotaro]]

With WebRender, video rendering could be disabled simply by removing async image pipeline.

Comment 1

[Sotaro Ikeda [:sotaro]]

From Bug 1682206 Comment 10 , it seems better to disable video rendering in graphics area.

Comment 2

[Sotaro Ikeda [:sotaro]]

Attachment: Bug 1684194 - Disable video rendering during cloning video with WebRender

Comment 3

[Sotaro Ikeda [:sotaro]]

https://treeherder.mozilla.org/jobs?repo=try&revision=1b2faa6d6dd367d23a377779fb300482cc18e6c9

Comment 4

[Robert Mader [:rmader]]

Hej Sotaro, any news on this? IIUC this blocks bug 1682471 ?

Comment 5

[Sotaro Ikeda [:sotaro]]

(In reply to Robert Mader [:rmader] from comment #4)

Hej Sotaro, any news on this? IIUC this blocks bug 1682471 ?

Sorry, I am going to work for it next week. It could be one workaround of bug 1682471 . But it does not address root cause of the flickering problem. It is ideal to address the root cause. There could be some ways to address the root cause. Though I am not sure if it is possible.
-[1] Allocate shared GL context of WebRender and uses RenderCompositorEGL instead of RenderCompositorOGL
-[2] Make RenderDMABUFTextureHost robust from multiple GLContexts of WebRender usage

Comment 6

[Robert Mader [:rmader]]

(In reply to Sotaro Ikeda [:sotaro] from comment #5)

(In reply to Robert Mader [:rmader] from comment #4)

Hej Sotaro, any news on this? IIUC this blocks bug 1682471 ?

Sorry, I am going to work for it next week.

Thanks! :) Even if that doesn't solve the root cause, it might reduce the chance of running into the issue enough to switch on EGL by default.

It could be one workaround of bug 1682471 . But it does not address root cause of the flickering problem. It is ideal to address the root cause. There could be some ways to address the root cause. Though I am not sure if it is possible.
-[1] Allocate shared GL context of WebRender and uses RenderCompositorEGL instead of RenderCompositorOGL

Yeah, that's what I first tried in bug 1640048 but it turned out to be more complex, so I went for the easy option. I suppose it would be the better solution long term, sharing even more code between X11 and Wayland/Android, and did not yet see a strong reason why it wouldn't work.

-[2] Make RenderDMABUFTextureHost robust from multiple GLContexts of WebRender usage

Martin, do you have a opinion which of the two solutions here is more feasible?

Comment 7

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

(In reply to Robert Mader [:rmader] from comment #6)

It could be one workaround of bug 1682471 . But it does not address root cause of the flickering problem. It is ideal to address the root cause. There could be some ways to address the root cause. Though I am not sure if it is possible.
-[1] Allocate shared GL context of WebRender and uses RenderCompositorEGL instead of RenderCompositorOGL

Yeah, that's what I first tried in bug 1640048 but it turned out to be more complex, so I went for the easy option. I suppose it would be the better solution long term, sharing even more code between X11 and Wayland/Android, and did not yet see a strong reason why it wouldn't work.

-[2] Make RenderDMABUFTextureHost robust from multiple GLContexts of WebRender usage

Martin, do you have a opinion which of the two solutions here is more feasible?

Wayland/X11 EGL backend can use both RenderDMABUFTextureHost (for vaapi/WebGL) and EGLImageTextureHost (for sw rendering) so fixes at RenderDMABUFTextureHost will affects only vaapi playback so [1] looks more useful to me.

Comment 8

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

Looking at https://bugzilla.mozilla.org/show_bug.cgi?id=1682471#c1 it seems to affects vaapi playback so RenderDMABUFTextureHost will be sufficient here. DMABuf surfaces may be easily shared across processes/contents without actual memory copy.

Comment 9

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

I'm working on the shared GL context for EGL/X11, there's no reason to use different paths for Wayland/X11 there. RenderDMABUFTextureHost may not be significant (or it's a different issue) as I see the bug with default non-dmabuf textures too.

Comment 10

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

Attachment: Bug 1684194 [Linux] Use RenderCompositorEGL on X11/EGL, r?sotaro

Comment 11

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

With the patch above we use the same rendering path for Wayland/EGL and X11/EGL. One difference here is that we don't pause WebRender then nsWindow becomes hidden but we resume rendering only once when nsWindow is created. We need to do this resume to force create mSurface at RenderCompositorEGL::Resume().

If you think we also should pause WebRender when the window is hidden on X11/EGL I can update the patch.
Thanks.

Comment 12

[Sotaro Ikeda [:sotaro]]

deleted

Comment 13

[Sotaro Ikeda [:sotaro]]

Attachment: Screenshot with D108508 with xwayland

With D108508 applied, when I run Firefox with "MOZ_X11_EGL=1 ./mach run". Rendering was broken. Ubuntu was 18.04 with xwayland(login with ubuntu with wayland). I did not see the problem with x11(login with ubuntu).

Comment 14

[Sotaro Ikeda [:sotaro]]

:stransky, is comment 13 expected to happen?

Comment 15

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

:sotaro yes, partially. Looks like transparent / alpha visual is used and alpha is not correctly configured. It may be a variant of Bug 1663003 and we should fix that. It also depends on your gfx card/drivers - which one do you run?
Thanks.

Comment 16

[Sotaro Ikeda [:sotaro]]

about:support says the following.

GPU #1
Description NV126
Vendor ID 0x10de
Device ID 0x1401
Driver Vendor mesa/nouveau
Driver Version 19.2.8.0

Comment 17

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

Yes, nvidia is know to be buggy and we don't going to use EGL there. It also does not support dmabuf buffers so there's no reason to use it.

Comment 18

[Sotaro Ikeda [:sotaro]]

OK, thank you.

Comment 19

[Robert Mader [:rmader]]

(In reply to Martin Stránský [:stransky] from comment #17)

Yes, nvidia is know to be buggy and we don't going to use EGL there. It also does not support dmabuf buffers so there's no reason to use it.

IIUC this is nouveau/mesa, so dmabuf is available and we probably want to use WR+EGL there eventually.

However, nouveau tends to be buggy and the version is not quite the newest - and Xwayland is also in the mix. Sotaro: any chance you can test on something more recent, such as Ubuntu 20.04? It should have a much better Wayland experience.

Comment 20

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

(In reply to Robert Mader [:rmader] from comment #19)

(In reply to Martin Stránský [:stransky] from comment #17)

Yes, nvidia is know to be buggy and we don't going to use EGL there. It also does not support dmabuf buffers so there's no reason to use it.

IIUC this is nouveau/mesa, so dmabuf is available and we probably want to use WR+EGL there eventually.

However, nouveau tends to be buggy and the version is not quite the newest - and Xwayland is also in the mix. Sotaro: any chance you can test on something more recent, such as Ubuntu 20.04? It should have a much better Wayland experience.

I tried hard to make dmabuf/EGL working on my NV 750Ti/noveau/Fedora 32/33 but I failed. I don't think it's worth the time we may need to invest there.

Comment 21

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/52299c7cbec4
[Linux] Use RenderCompositorEGL on X11/EGL, r=sotaro

Comment 22

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/52299c7cbec4

Comment 23

[angelsl]

Bug #1699961 is probably a regression. (Bug #1700030 is probably a duplicate)