Closed Bug 1835797 Opened 1 year ago Closed 1 year ago

[VA-API] Don't run VA-API test on SW renderer

Categories

(Core :: Widget: Gtk, defect)

defect

Tracking

()

RESOLVED FIXED
115 Branch
Tracking Status
firefox115 --- fixed

People

(Reporter: stransky, Assigned: stransky)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

Recently VA-API test can be run on SW renderer/virtual machine on start.

Flags: needinfo?(stransky)

VAAPI/SW WR is blocked late in media: https://searchfox.org/mozilla-central/source/dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp#412

But it doesn't block VAAPI/"HW" WR/llvmpipe.

Maybe also block SW WR sooner here:
https://searchfox.org/mozilla-central/rev/0c2945ad4769e2d4428c72e6ddd78d60eb920394/gfx/thebes/gfxPlatformGtk.cpp#258

  if (gfxVars::UseSoftwareWebRender()) {
    feature.ForceDisable(FeatureStatus::Unavailable, "Requires HW WebRender",
                         "FEATURE_FAILURE_REQUIRES_HW_WR"_ns);
  }

and also block VAAPI/HW WR/SoftwareMesaAll:
https://searchfox.org/mozilla-central/rev/0c2945ad4769e2d4428c72e6ddd78d60eb920394/widget/gtk/GfxInfo.cpp#926

    // Disable on llvmpipe
    APPEND_TO_DRIVER_BLOCKLIST_EXT(
        OperatingSystem::Linux, ScreenSizeStatus::All, BatteryStatus::All,
        WindowProtocol::All, DriverVendor::SoftwareMesaAll, DeviceFamily::All,
        nsIGfxInfo::FEATURE_WEBRENDER, nsIGfxInfo::FEATURE_BLOCKED_DEVICE,
        DRIVER_COMPARISON_IGNORED, V(0, 0, 0, 0), "FEATURE_HARDWARE_VIDEO_DECODING_NO_SW_GL",
        "");

but such a rule alone would still allow force-enabling VAAPI on force-enabled HW WR on llvmpipe. :-/

Offtopic: IIUC, bug 1777430 also shipped bug 1833354 (once it's actually used). :)

That's interesting, Thanks. And do you know how to force-enable HW WR on llvmpipe?

Flags: needinfo?(stransky)

https://hg.mozilla.org/integration/autoland/rev/a44d91198e01 removed the UseDMABuf and IsDMABufEnabled checks from IsDMABufVAAPIEnabled back then for nvidia-vaapi-driver. VAAPI might still work if "DMABUF" failed. (?)

$ LIBGL_ALWAYS_SOFTWARE=1 mozregression --launch 2023-05-30 -a about:support --pref gfx.webrender.all:true media.hardware-video-decoding.force-enabled:true

Compositing WebRender

WebGL 1 Driver Renderer Mesa/X.org -- llvmpipe (LLVM 15.0.6, 256 bits)
WebGL 1 Driver Version 4.5 (Compatibility Profile) Mesa 22.3.6

DMABUF
default available
runtime failed Failed to configure Blocklisted; failure code FEATURE_FAILURE_NO_DRM_DEVICE

HARDWARE_VIDEO_DECODING
default available
user force_enabled Force enabled by pref
runtime unavailable Force disabled by gfxInfo Blocklisted; failure code FEATURE_FAILURE_VIDEO_DECODING_TEST_FAILED

force-enabling comes after force-disabling, so I assume it's force-enabled:
https://searchfox.org/mozilla-central/rev/0c2945ad4769e2d4428c72e6ddd78d60eb920394/gfx/thebes/gfxPlatformGtk.cpp#244

[...]
} else if (status == nsIGfxInfo::FEATURE_BLOCKED_PLATFORM_TEST) {
feature.ForceDisable(FeatureStatus::Unavailable,
"Force disabled by gfxInfo", failureId);
[...]
if (aForceEnabledByUser) {
feature.UserForceEnable("Force enabled by pref");
}
[...]

(Sorry, submitted a bit too soon, comment is corrected now.)

No, my guess seems to be wrong, VAAPI with force-enabled [VAAPI,DMABUF,HW WR] on llvmpipe seems to be blocked by vaapi test:

MOZ_LOG="Dmabuf:5,PlatformDecoderModule:5" LIBGL_ALWAYS_SOFTWARE=1 mozregression --launch 2023-05-30 -P stdout --pref gfx.webrender.all:true media.hardware-video-decoding.force-enabled:true widget.dmabuf.force-enabled:true -a https://bug1619882.bmoattachments.org/attachment.cgi?id=9149605

0:20.67 INFO: b"[Parent 12999: Main Thread]: D/Dmabuf We're missing DRM render device!"
0:20.75 INFO: b'[GFX1-]: vaapitest: ERROR'
0:20.75 INFO: b'[GFX1-]: vaapitest: VA-API test failed: failed to open renderDeviceFD.'

MOZ_DRM_DEVICE="/dev/dri/renderD128" MOZ_LOG="Dmabuf:5,PlatformDecoderModule:5" LIBGL_ALWAYS_SOFTWARE=1 mozregression --launch 2023-05-30 -P stdout --pref gfx.webrender.all:true media.hardware-video-decoding.force-enabled:true widget.dmabuf.force-enabled:true -a https://bug1619882.bmoattachments.org/attachment.cgi?id=9149605

0:27.73 INFO: b'[Parent 13518: Main Thread]: D/Dmabuf DMABuf is enabled'
0:27.79 INFO: b'[GFX1-]: vaapitest: ERROR'
0:27.79 INFO: b'[GFX1-]: vaapitest: VA-API test failed: failed to open renderDeviceFD.'

No other occurences of Dmabuf, VAAPI, VA-API.

This check blocks force-enabled VAAPI on force-enabled HW WR on llvmpipe:
https://searchfox.org/mozilla-central/rev/0c2945ad4769e2d4428c72e6ddd78d60eb920394/dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp#402

0:28.98 INFO: b'[RDD 15453: MediaSupervisor #1]: D/PlatformDecoderModule FFMPEG: Codec h264 is not accelerated'

Yes, it's disabled but we still launch vaapitest binary on llvmpipe because we disable VA-API a bit late. We should disable it when the feature is initialized so we don't spend time on startup with vaapitest then.

Pushed by stransky@redhat.com: https://hg.mozilla.org/integration/autoland/rev/d208bee81609 [Linux] Don't launch vaapitest on software backends r=emilio
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 115 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: