WebGL never uses Dmabuf any more
Categories
(Core :: Graphics: Layers, defect)
Tracking
()
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)
(deleted),
text/x-phabricator-request
|
dmeehan
:
approval-mozilla-beta+
|
Details |
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).
Updated•2 years ago
|
Comment 1•2 years ago
|
||
Set release status flags based on info from the regressing bug 1776348
Assignee | ||
Comment 2•2 years ago
|
||
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.
Updated•2 years ago
|
Comment 4•2 years ago
|
||
bugherder |
Comment 5•2 years ago
|
||
We should uplift that to 103.
Updated•2 years ago
|
Comment 6•2 years ago
|
||
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
Updated•2 years ago
|
Updated•2 years ago
|
Comment 7•2 years ago
|
||
Comment on attachment 9282925 [details]
Bug 1776563 - Remove nsDMABufDevice::IsDMABufEnabled(), r=stransky
Approved for 103 beta 2, thanks.
Comment 8•2 years ago
|
||
bugherder uplift |
Assignee | ||
Updated•2 years ago
|
Updated•2 years ago
|
Comment 9•2 years ago
|
||
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•2 years ago
|
||
You need to use Linux, not Windows.
Comment 11•2 years ago
|
||
(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?
Assignee | ||
Comment 13•2 years ago
|
||
The effect depends on the hardware, but yes, that's roughly what should happen :)
Comment 14•2 years ago
|
||
Mark as verified based on comment #13.
Description
•