Closed Bug 1776563 Opened 2 years ago Closed 2 years ago

WebGL never uses Dmabuf any more

Categories

(Core :: Graphics: Layers, defect)

defect

Tracking

()

RESOLVED FIXED
104 Branch
Tracking Status
firefox-esr91 --- unaffected
firefox-esr102 --- unaffected
firefox101 --- unaffected
firefox102 --- unaffected
firefox103 --- verified
firefox104 --- verified

People

(Reporter: rmader, Assigned: rmader)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression)

Attachments

(1 file)

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).

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

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.

Pushed by robert.mader@posteo.de: https://hg.mozilla.org/integration/autoland/rev/b66edd978d47 Remove nsDMABufDevice::IsDMABufEnabled(), r=stransky
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 104 Branch

We should uplift that to 103.

Flags: needinfo?(stransky)

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
Flags: needinfo?(stransky)
Attachment #9282925 - Flags: approval-mozilla-beta?
Flags: qe-verify+

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

Approved for 103 beta 2, thanks.

Attachment #9282925 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
QA Whiteboard: [qa-triaged]

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.

Flags: needinfo?(robert.mader)

You need to use Linux, not Windows.

(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?

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

Flags: needinfo?(robert.mader)
Regressions: 1778114
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: