1700439 - VAAPI: "Dmabuf Failed: We're missing DRM render device!" (It works with MOZ_WAYLAND_DRM_DEVICE=/dev/dri/renderD128)

Status: RESOLVED WORKSFORME

(Core :: Audio/Video: Playback, defect, P3)

Description

[c.t.blakley]

Attachment: firefox_aboutsupport.txt

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:87.0) Gecko/20100101 Firefox/87.0

Steps to reproduce:

Enabled VA-API required environment details: WebRender enabled, using Wayland, and set media.ffmpeg.vaapi.enabled=true. Run firefox as:

MOZ_LOG="PlatformDecoderModule:5,Dmabuf:5" MOZ_ENABLE_WAYLAND=1 MOZ_WEBRENDER=1 firefox

Actual results:

VA-API is disabled:

[Parent 5174: Main Thread]: D/Dmabuf wl_drm is available.
[Parent 5174: Main Thread]: D/Dmabuf zwp_linux_dmabuf_v1 is available.
[Child 5317: Main Thread]: D/Dmabuf wl_drm is available.
[Child 5317: Main Thread]: D/Dmabuf zwp_linux_dmabuf_v1 is available.
[Child 5354: Main Thread]: D/Dmabuf wl_drm is available.
[Child 5354: Main Thread]: D/Dmabuf zwp_linux_dmabuf_v1 is available.
[Child 5469: Main Thread]: D/Dmabuf wl_drm is available.
[Child 5469: Main Thread]: D/Dmabuf zwp_linux_dmabuf_v1 is available.
[Child 5524: Main Thread]: D/Dmabuf wl_drm is available.
[Child 5524: Main Thread]: D/Dmabuf zwp_linux_dmabuf_v1 is available.
[Child 5524: Main Thread]: D/PlatformDecoderModule PDMInitializer, Init PDMs in Content process
[Child 5524: Main Thread]: D/PlatformDecoderModule VA-API FFmpeg is disabled by platform
[Child 5524: Main Thread]: D/PlatformDecoderModule VA-API FFmpeg is disabled by platform
[Child 5524: Main Thread]: D/PlatformDecoderModule Sandbox RDD decoder supports requested type
[Child 5524: Main Thread]: D/PlatformDecoderModule Sandbox RDD decoder supports requested type
[RDD 5676: Main Thread]: D/PlatformDecoderModule PDMInitializer, Init PDMs in RDD process
[RDD 5676: Main Thread]: D/PlatformDecoderModule VA-API FFmpeg is disabled by platform

Expected results:

VA-API decoding for h264 should be enabled. Confirmed working with other applications (Chromium, mpv). Also compiled system ffmpeg with --enable-vaapi.

Comment 1

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

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

Comment 2

[Alastor Wu [:alwu]]

Because currently we decode video in a remote process (RDD) where we haven't enabled the VAAPI yet because of some sandboxed issues. It will be done in bug1683808.

Comment 3

[Alastor Wu [:alwu]]

Hmm, butI saw VAAPI also got disabled in your content process. By checking the enabling condition [1], it seems you need to enable media.ffmpeg.dmabuf-textures.disabled as well. But anyway, our long term goal is to enable VAAPI in RDD process.

[1]
https://searchfox.org/mozilla-central/rev/cc4a17cea338fe236626d838ca96e9bf6a775675/dom/media/platforms/ffmpeg/FFmpegLibWrapper.cpp#262
https://searchfox.org/mozilla-central/source/widget/gtk/DMABufLibWrapper.cpp#277-279

Comment 4

[Darkspirit]

(Enabling media.ffmpeg.dmabuf-textures.disabled would disable dmabuf-textures (fast upload of software-decoded video).
dmabuf-textures are required for VAAPI hardware video decoding.)

I assume you are not using h264 vaapi because you get a VP9 video. You need to Install the addon for YouTube.

For VAAPI on YouTube one usually needs:

• media.rdd-vpx.enabled=false (You might not need this as you only want h264.)
• media.ffmpeg.vaapi.enabled=true
• gfx.webrender.all=true
• Disable AV1 or VP9 if your GPU doesn't support them (VP9 is required for 4K on YouTube): https://addons.mozilla.org/firefox/addon/enhanced-h264ify
  Right click on a YouTube video and make sure it's using the avc codec (h264).
• Start Firefox with MOZ_ENABLE_WAYLAND=1 env var on Wayland, or MOZ_X11_EGL=1 on Xwayland&X11.

Comment 5

[c.t.blakley]

I was not testing on YouTube, I'm testing on Twitch, which streams native h264. I installed eh2654ify and tested on YouTube and got the same result. Performed with all the settings you describe: media.ffmpeg.vaapi.enabled=true, gfx.webrender.all=true, MOZ_ENABLE_WAYLAND=1. I just tried again with media.rdd-vpx.enabled=false and also got the same result.

Comment 6

[Darkspirit]

There is a second apparently disabled Nvidia GPU, it might break things.

"adapterVendorID2": "0x10de",
"adapterDeviceID2": "0x2204",
"isGPU2Active": false,

Your primary AMD GPU seems to be from ~2014 and only supports h264.
Firefox uses VAAPI with platform-neutral Dmabuf (vaExportSurfaceHandle) on Wayland, Xwayland and X11.
Other video players use VAAPI with X11 pixmaps. Therefore they could even use the VAAPI-via-VDPAU package.
It seems you are using the Mesa driver. (The proprietary Nvidia driver doesn't support Dmabuf yet. It might this summer, but it still wouldn't support VAAPI. And, IIRC, the VAAPI-via-VDPAU adapter does not support Dmabuf.)

Possible problem sources:

• If the VAAPI-via-VDPAU library is installed and used, VAAPI can't be used with Dmabuf on Mesa.
• Firefox device detection might still be broken in some way. bug 1588904 and bug 1676883 should have fixed it.
  Would the environment variable MOZ_WAYLAND_DRM_DEVICE=/dev/dri/renderD128 (or /dev/dri/renderD129) help?
• You might have set other prefs that disable Dmabuf or hardware video decoding.
• Your GPU might be too old for Dmabuf. (I don't know if such cases exist.)

Does $ vainfo --display drm --device /dev/dri/renderD128 advertise support for h264 or does it show any error?

Comment 7

[c.t.blakley]

The secondary NVIDIA GPU is owned permanently by the VFIO driver and should not be considered at all. Neither the proprietary Nvidia driver nor Nouveau are installed. I do not have any VAAPI<->VDPAU translation layers installed.

MOZ_WAYLAND_DRM_DEVICE=/dev/dri/renderD128 produces the following additional log message interspersed within the original one posted:

[Child 275319: Main Thread]: D/Dmabuf GBM device initialized

And it works when set with this! So it appears device detection is still imperfect. But I can modify my environment to deal with it. Thank you.

Comment 8

[Darkspirit]

Thanks for testing! Please also test https://nightly.mozilla.org to check if setting prefs is enough there or if it still requires MOZ_WAYLAND_DRM_DEVICE to be set.

Comment 9

[c.t.blakley]

Nightly does still require MOZ_WAYLAND_DRM_DEVICE to be set. It produces this additional log message when it is not set:

[Child 294282: Main Thread]: D/Dmabuf nsDMABufDevice::Configure() [Child 294282: Main Thread]: D/Dmabuf Loading DMABuf system library libgbm.so.1 ... [Child 294282: Main Thread]: D/Dmabuf Failed: We're missing DRM render device! [Child 294282: Main Thread]: D/Dmabuf nsDMABufDevice::IsDMABufVAAPIEnabled: EGL 1 DMABufEnabled 0 media_ffmpeg_vaapi_enabled 1 CanUseHardwareVideoDecoding 1 !XRE_IsRDDProcess 1

Comment 10

[Robert Mader [:rmader]]

As this is on AMD, could be a dup of bug 1693065 which turned out to be a libdrm bug, see bug 1693065 comment 7 / https://gitlab.freedesktop.org/mesa/drm/-/issues/56

Comment 11

[c.t.blakley]

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

As this is on AMD, could be a dup of bug 1693065 which turned out to be a libdrm bug, see bug 1693065 comment 7 / https://gitlab.freedesktop.org/mesa/drm/-/issues/56

That seems likely. It looks like mesa 21.0 should have that bug fixed - Arch is still shipping 20.0.

Comment 12

[Robert Mader [:rmader]]

(In reply to c.t.blakley from comment #11)

That seems likely. It looks like mesa 21.0 should have that bug fixed - Arch is still shipping 20.0.

The libdrm issue is fixed in libdrm, not mesa :p
However, looking at https://gitlab.freedesktop.org/mesa/drm/-/commits/master/ there hasn't been a new release yet - latest one is 2.4.104 which does not yet include the fixes. So you'll have to wait for 2.4.105 :/

Comment 13

[c.t.blakley]

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

(In reply to c.t.blakley from comment #11)

That seems likely. It looks like mesa 21.0 should have that bug fixed - Arch is still shipping 20.0.

The libdrm issue is fixed in libdrm, not mesa :p
However, looking at https://gitlab.freedesktop.org/mesa/drm/-/commits/master/ there hasn't been a new release yet - latest one is 2.4.104 which does not yet include the fixes. So you'll have to wait for 2.4.105 :/

Right, sorry. Didn't read closely enough. In that case I'm no longer sure if this bug will be resolved by the libdrm fix - I just compiled it from the current state of master and it did not resolve.

Comment 14

[Robert Mader [:rmader]]

Does this issue still reproduce for you? Thanks!

Comment 15

[c.t.blakley]

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

Does this issue still reproduce for you? Thanks!

Nope, working now on Firefox 93, latest Arch. Same physical configuration as before with the secondary NVIDIA GPU that should not be considered, is now properly ignored, and the AMD GPU is properly detected. Thank you!

Comment 16

[Robert Mader [:rmader]]

Awesome, thanks :)