Closed Bug 1730936 Opened 1 year ago Closed 6 months ago

DMFBuf does not work on Pinebook Pro/Rockchip RK3399

Categories

(Core :: Graphics: WebRender, defect)

Firefox 92
ARM64
Linux
defect

Tracking

()

RESOLVED FIXED
105 Branch
Tracking Status
firefox105 --- fixed

People

(Reporter: monkeyboyted, Assigned: rmader)

References

(Blocks 2 open bugs, )

Details

Attachments

(8 files, 3 obsolete files)

Attached file init_about_support.txt

User Agent: Mozilla/5.0 (X11; Linux aarch64; rv:92.0) Gecko/20100101 Firefox/92.0

Steps to reproduce:

  1. Enable gfx.webrender.all gfx.compositor.forced-enabled gfx.webrender.compositor
  2. Start Firefox in wayland
    $MOZ_ENABLE_WAYLAND=1 firefox
  3. Navigate to about support
  4. Look at DMABUF

Actual results:

Firefox prints out this error in the shell

Crash Annotation GraphicsCriticalError: |[0][GFX1-]: Failed to create EGLContext!: 0x3009 (t=1.17142) [GFX1-]: Failed to create EGLContext!: 0x3009

About:support

DMABUF
available by default
failed by runtime: Failed to configure

disabled by default: Disabled by default
force_enabled by user: Force enabled by pref
blocklisted by env: Blocklisted by gfxInfo
unavailable by runtime: Hardware Webrender requires DMAbuf support

Expected results:

Firefox should report DMABUF is available because the pinebook pro uses Panfront/Bitfrost opensource driver

I believe Collabora invested in that particular Mali driver.

OS: Unspecified → Linux
Hardware: Unspecified → ARM64

The Bugbug bot thinks this bug should belong to the 'Core::Graphics: WebRender' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Graphics: WebRender
Product: Firefox → Core
Attached file glxinfo.txt

glxinfo

Thanks, that should be enough for the moment for us to start debugging! There's one thing I'd like to ask you: could you also check latest nightly[1] and paste the output of about:support for that (once vanilla/with default settings, once with MOZ_ENABLE_WAYLAND=1)?

1: https://www.mozilla.org/en-GB/firefox/channel/desktop/#nightly

Linux aarch64

There is no official arm64 Linux Nightly yet.
Autoland has arm64 Linux builds, but not every autoland build has one.

  1. Open https://treeherder.mozilla.org/jobs?repo=autoland&tier=2
  2. Search for "Linux AArch64 opt" with a green "B"
  3. Then click on "Artifacts" and download target.tar.bz2. It's like a Nightly without updater.

94.0a1 (2021-09-15) (64-bit)

Attached file vanilla_nightly_about_support.json (obsolete) —

My apologies. Here is a completely vanilla about support in json format. The earlier file has glx.webrender.all, glx.webrender.compositor and glx.webrender.compositor.force-enabled enabled.

"windowProtocol": "wayland",
Driver Vendor: mesa/swrast

See Also: → 1725624
Attached file vanilla_nightly_about_support.json (obsolete) —

I accidentally turned on MOZ_ENABLE_WAYLAND=1

What log do you get in the terminal if start Nightly with MOZ_LOG="Dmabuf:5" ./firefox?

Hi Darkspirit,

I am sorry I am late

MOZ_LOG="Dmabuf:5" ./firefox-bin
[Parent 38218: Main Thread]: D/Dmabuf wl_drm is available.
[Parent 38218: Main Thread]: D/Dmabuf zwp_linux_dmabuf_v1 is available.
[Parent 38218: Main Thread]: D/Dmabuf nsDMABufDevice::Configure()
[Parent 38218: Main Thread]: D/Dmabuf Loading DMABuf system library libgbm.so.1 ...
[Parent 38218: Main Thread]: D/Dmabuf Failed: We're missing DRM render device!

Firefox nightly

Comment 8 and comment 10 appear to have invalid JSON content - they don't open for me. Please use "Copy text to clipboard" in about:support instead.

(In reply to monkeyboyted from comment #12)

...
[Parent 38218: Main Thread]: D/Dmabuf Failed: We're missing DRM render device!

Thanks, then we roughly know where the issue lies[1]. Will have a look.

1: https://searchfox.org/mozilla-central/source/toolkit/xre/glxtest.cpp#402-407

Assignee: nobody → robert.mader
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #9241408 - Attachment mime type: application/json → text/plain
Attachment #9241410 - Attachment mime type: application/json → text/plain

Resubmit moz enabled about support

Attached file vanilla_nightly_about_support.txt (obsolete) —

Resubmitting about support into plain text

Attachment #9241408 - Attachment is obsolete: true
Attachment #9241410 - Attachment is obsolete: true

I realize that MOZ_ENABLE_WAYLAND was set globally on my computer. Do'h. Now, it is vanilla with all these gtk warnings.

(firefox:5176): Gtk-WARNING **: 13:28:50.735: Theme parsing error: gtk.css:68:35: The style property GtkButton:child-displacement-x is deprecated and shouldn't be used anymore. It will be removed in a future version

(firefox:5176): Gtk-WARNING **: 13:28:50.736: Theme parsing error: gtk.css:69:35: The style property GtkButton:child-displacement-y is deprecated and shouldn't be used anymore. It will be removed in a future version

(firefox:5176): Gtk-WARNING **: 13:28:50.736: Theme parsing error: gtk.css:73:46: The style property GtkScrolledWindow:scrollbars-within-bevel is deprecated and shouldn't be used anymore. It will be removed in a future version

(firefox:5176): Gtk-WARNING **: 13:28:50.833: Theme parsing error: gtk.css:68:35: The style property GtkButton:child-displacement-x is deprecated and shouldn't be used anymore. It will be removed in a future version

(firefox:5176): Gtk-WARNING **: 13:28:50.833: Theme parsing error: gtk.css:69:35: The style property GtkButton:child-displacement-y is deprecated and shouldn't be used anymore. It will be removed in a future version

(firefox:5176): Gtk-WARNING **: 13:28:50.833: Theme parsing error: gtk.css:73:46: The style property GtkScrolledWindow:scrollbars-within-bevel is deprecated and shouldn't be used anymore. It will be removed in a future version

(firefox:5176): Gtk-WARNING **: 13:28:50.953: Theme parsing error: gtk.css:68:35: The style property GtkButton:child-displacement-x is deprecated and shouldn't be used anymore. It will be removed in a future version

(firefox:5176): Gtk-WARNING **: 13:28:50.953: Theme parsing error: gtk.css:69:35: The style property GtkButton:child-displacement-y is deprecated and shouldn't be used anymore. It will be removed in a future version

(firefox:5176): Gtk-WARNING **: 13:28:50.953: Theme parsing error: gtk.css:73:46: The style property GtkScrolledWindow:scrollbars-within-bevel is deprecated and shouldn't be used anymore. It will be removed in a future version

(firefox:5176): Gtk-WARNING **: 13:28:51.049: Theme parsing error: gtk.css:68:35: The style property GtkButton:child-displacement-x is deprecated and shouldn't be used anymore. It will be removed in a future version

(firefox:5176): Gtk-WARNING **: 13:28:51.049: Theme parsing error: gtk.css:69:35: The style property GtkButton:child-displacement-y is deprecated and shouldn't be used anymore. It will be removed in a future version

(firefox:5176): Gtk-WARNING **: 13:28:51.049: Theme parsing error: gtk.css:73:46: The style property GtkScrolledWindow:scrollbars-within-bevel is deprecated and shouldn't be used anymore. It will be removed in a future version

Attachment #9241664 - Attachment is obsolete: true

The GTK theme warnings suggest that you are using a non-default theme which needs to get updated. Unlikely we can do anything about it on the Firefox side.

It looks to me like like what we need to do here is use the new EGL_EXT_device_drm_render_node extension. IIUC it would replace what we currently do in [3], even though we need to keep that around as a fallback.

For the record, given that the V3D driver is currently buggy on HW-WR (bug 1725624) and thus should not be activated by default, there's also no DmaBuf usage by default. I.e. this has a rather low priority for me, even though it would be good to have.

1: https://github.com/KhronosGroup/EGL-Registry/pull/127
2: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11797
3: https://searchfox.org/mozilla-central/source/toolkit/xre/glxtest.cpp#351-420

The severity field is not set for this bug.
:jimm, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(jmathies)
Severity: -- → S4
Flags: needinfo?(jmathies)
Blocks: raspi
Blocks: wr-linux-pine64
No longer blocks: raspi

We have a custom render node discovery code (needed for DMABUF) that
predates the EGL_DRM_RENDER_NODE_FILE_EXT extension. It has additional
value that it helps us discover the right vendor and device ID on
multi-GPU setups (there's a EGL extension far that backing, but
not ready yet).
In case our custom code fails - notably split display/render SoCs,
which are common in the ARM world - lets use
EGL_DRM_RENDER_NODE_FILE_EXT as fallback. This will ensure we
get a valid render node path on all devices, assuming the driver
supports that extension right. These SoCs are usually no multi-GPU
systems. If they are, we still don't get the right IDs - but an
extension for that is in the making.

Note: Mesa does not implement this right for such SoCs, i.e. it
will fail just as our own custom code. However, there's a MR in
review - once it lands, things should start working, see
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12796

Depends on D134254

See Also: → 1738814
Pushed by robert.mader@posteo.de:
https://hg.mozilla.org/integration/autoland/rev/e5c53da802b9
Use EGL_DRM_RENDER_NODE_FILE_EXT in glxtest, r=gfx-reviewers,aosmond

As said before, this bug is not fixed by the patch above until https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12796 landed and got rolled out. Thus keeping this bug open till then.

Keywords: leave-open
See Also: → 1721053
See Also: 1721053

Some devices do not use the same DRM device for KMS and rendering. On
these, we currently don't manage to derive the right render node from
the KMS device. In many if not most such cases there is only a single
render node available on the system though. Thus use that as fallback.

Notes:

  • We only call this code if the driver in use advertices
    EGL_EXT_device_drm, i.e. is actually a DRM driver and thus
    should have a render node.

  • This should all become unnecessary once the respective drivers
    support EXT_device_drm_render_node - it does not look like that
    will happen soon though.

Pushed by robert.mader@posteo.de:
https://hg.mozilla.org/integration/autoland/rev/b5120429298b
Guess DRM render node if only one is available, r=gfx-reviewers,lsalzman
Attached file about_support_22_08_09

MOZ_LOG="Dmabuf:5" ./firefox-bin
[GFX1-]: glxtest: DRM render node not clearly detectable. Falling back to using the only one that was found.
[GFX1-]: glxtest: VA-API test failed: failed to initialise VAAPI connection.
[Parent 1738: Main Thread]: D/Dmabuf wl_drm is available.
[Parent 1738: Main Thread]: D/Dmabuf zwp_linux_dmabuf_v1 is available.
[Parent 1738: Main Thread]: D/Dmabuf Using DRM device /dev/dri/renderD128
[Parent 1738: Main Thread]: D/Dmabuf nsDMABufDevice::Configure()
[Parent 1738: Main Thread]: D/Dmabuf Loading DMABuf system library libgbm.so.1 ...
[Parent 1738: Main Thread]: D/Dmabuf DMABuf is enabled
[GFX1-]: Failed to create EGLContext!: 0x3009

I meant night build at that particular commit aka build id 20220809222238

I took the time to report the VAAPI connection bug

https://bugzilla.mozilla.org/show_bug.cgi?id=1783987

Status: ASSIGNED → RESOLVED
Closed: 6 months ago
Keywords: leave-open
Resolution: --- → FIXED
Target Milestone: --- → 105 Branch

ls /dev/dri/
by-path card0 card1 renderD128
[doop@hostname firefox]$ ls /dev/dri/by-path/
platform-display-subsystem-card platform-ff9a0000.gpu-card platform-ff9a0000.gpu-render

tree /dev/dri/
/dev/dri/
├── by-path
│   ├── platform-display-subsystem-card -> ../card0
│   ├── platform-ff9a0000.gpu-card -> ../card1
│   └── platform-ff9a0000.gpu-render -> ../renderD128
├── card0
├── card1
└── renderD128

monkeyboyted: thanks for that info, however there's no need for it any more :)

See Also: → 1784777
You need to log in before you can comment on or make changes to this bug.