1776563 - WebGL never uses Dmabuf any more

Status: RESOLVED FIXED

(Core :: Graphics: Layers, defect)

Description

[Robert Mader [:rmader]]

Bug 1776348 requires widget::GetDMABufDevice()->IsDMABufWebGLEnabled() to return true to enable Dmabuf, however that check is broken since we switched to the surfaceless EGL platform in bug 1770407 (and successively to the device platform in bug 1773377).

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1776348

Comment 2

[Robert Mader [:rmader]]

Attachment: Bug 1776563 - Remove nsDMABufDevice::IsDMABufEnabled(), r=stransky

We do not need a GBM device any more in child processes and in several
cases we're also not allowed to open it any more by the sandbox.

For remaining cases were we do need it in the parent process (the
fallback path in SharedSurface_DMABUF::Create, used for WebGL and the
experimental widget.dmabuf-textures.enabled feature, as well as in
WaylandBufferDMABUF::Create used by gfx.webrender.compositor), we
already call Configure() in gfxPlatformGtk::InitDmabufConfig() and set
gfx::gfxVars::UseDMABuf accordingly, making
nsDMABufDevice::IsDMABufWebGLEnabled() still return the correct value.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b66edd978d47
Remove nsDMABufDevice::IsDMABufEnabled(), r=stransky

Comment 4

[Iulian Moraru]

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

Comment 5

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

We should uplift that to 103.

Comment 6

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

Comment on attachment 9282925 [details]
Bug 1776563 - Remove nsDMABufDevice::IsDMABufEnabled(), r=stransky

Beta/Release Uplift Approval Request

• User impact if declined: Performance drop on WebGL for all Linux users.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: Open any WebGL sample (https://webglsamples.org/blob/blob.html) and check fps. It should match your monitor refresh rate (usually 60fps).
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): We accidentally disabled dmabuf/webgl and this one restores it.
• String changes made/needed: none
• Is Android affected?: No

Comment 7

[Donal Meehan [:dmeehan]]

Comment on attachment 9282925 [details]
Bug 1776563 - Remove nsDMABufDevice::IsDMABufEnabled(), r=stransky

Approved for 103 beta 2, thanks.

Comment 8

[Donal Meehan [:dmeehan]]

https://hg.mozilla.org/releases/mozilla-beta/rev/a45675cad8d1

Comment 9

[Monica Chiorean]

I could not reproduce the issue on Win10 using build 103.0a1(20220625212921) and opening link (https://webglsamples.org/blob/blob.html) displays the 60fps like on the fixed build, so I can not confirm the fix. Are there any other steps that I use in order to reproduce the issue?
If not can you please confirm issue is fixed on Beta 103 (https://archive.mozilla.org/pub/firefox/candidates/103.0b2-candidates/build1/) and Nightly 104 (https://archive.mozilla.org/pub/firefox/nightly/2022/06/2022-06-29-21-58-21-mozilla-central/)? Thank you so much.

Comment 10

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

You need to use Linux, not Windows.

Comment 11

[Monica Chiorean]

(In reply to Martin Stránský [:stransky] (ni? me) from comment #10)

You need to use Linux, not Windows.

I used Ubuntu 20.4 with build 103.0a1(20220625212921) and the fps keep changing and rarely gets to 60fps, while on Beta 103.0b2 and Nightly the fps also changes but it shows 60fps more often. Is this the intended behavior?

Comment 13

[Robert Mader [:rmader]]

The effect depends on the hardware, but yes, that's roughly what should happen :)

Comment 14

[Monica Chiorean]

Mark as verified based on comment #13.