[Bug]: vaCreateSurfaces (import mode) failed, VA error: resource allocation failed

[stolk]

Which component impacted?

Decode

Is it regression? Good in old configuration?

104.0.5112.101 debian package, provided by Intel: works.

105.0.5195.19-hwacc snap package, fails in vaCreateSurfaces().

What happened?

Build chromium, enable vaapi, and then run chromium on a wayland desktop.

Instead of using HW decoding, chromium shows this libva error:

vaCreateSurfaces (import mode) failed, VA error: resource allocation failed

I traced this down to an unsupported modifier: I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC

Full write up here: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1990010

NOTE: HW decoding in chromium does work when on X11 desktop.

NOTE: I've seen this on both Alderlake and Tigerlake systems.

NOTE: va trace is available here: https://launchpadlibrarian.net/625015064/va.log.161716.thd-0x00021d72

What's the usage scenario when you are seeing the problem?

Web browser

What impacted?

Chromium on wayland.

Chromium snap version: 105.0.5195.19-hwacc

Debug Information

libva 2.15.0

gmmlib 22.2.0

media-driver 22.4.4

/dev/dri/card0 Alderlake iGPU

Do you want to contribute a patch to fix the issue?

No response

[stolk]

VA TRACE
va.log.161716.thd-0x00021d72.txt

[stolk]

vainfo output:

$ vainfo 
libva info: VA-API version 1.15.0
libva info: User environment variable requested driver 'iHD'
libva info: Trying to open /snap/vainfo/x9/usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_15
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.15 (libva 2.15.0)
vainfo: Driver version: Intel iHD driver for Intel(R) Gen Graphics - 22.4.4 ()
vainfo: Supported profile and entrypoints
      VAProfileNone                   :	VAEntrypointVideoProc
      VAProfileNone                   :	VAEntrypointStats
      VAProfileMPEG2Simple            :	VAEntrypointVLD
      VAProfileMPEG2Simple            :	VAEntrypointEncSlice
      VAProfileMPEG2Main              :	VAEntrypointVLD
      VAProfileMPEG2Main              :	VAEntrypointEncSlice
      VAProfileH264Main               :	VAEntrypointVLD
      VAProfileH264Main               :	VAEntrypointEncSlice
      VAProfileH264Main               :	VAEntrypointFEI
      VAProfileH264Main               :	VAEntrypointEncSliceLP
      VAProfileH264High               :	VAEntrypointVLD
      VAProfileH264High               :	VAEntrypointEncSlice
      VAProfileH264High               :	VAEntrypointFEI
      VAProfileH264High               :	VAEntrypointEncSliceLP
      VAProfileVC1Simple              :	VAEntrypointVLD
      VAProfileVC1Main                :	VAEntrypointVLD
      VAProfileVC1Advanced            :	VAEntrypointVLD
      VAProfileJPEGBaseline           :	VAEntrypointVLD
      VAProfileJPEGBaseline           :	VAEntrypointEncPicture
      VAProfileH264ConstrainedBaseline:	VAEntrypointVLD
      VAProfileH264ConstrainedBaseline:	VAEntrypointEncSlice
      VAProfileH264ConstrainedBaseline:	VAEntrypointFEI
      VAProfileH264ConstrainedBaseline:	VAEntrypointEncSliceLP
      VAProfileHEVCMain               :	VAEntrypointVLD
      VAProfileHEVCMain               :	VAEntrypointEncSlice
      VAProfileHEVCMain               :	VAEntrypointFEI
      VAProfileHEVCMain               :	VAEntrypointEncSliceLP
      VAProfileHEVCMain10             :	VAEntrypointVLD
      VAProfileHEVCMain10             :	VAEntrypointEncSlice
      VAProfileHEVCMain10             :	VAEntrypointEncSliceLP
      VAProfileVP9Profile0            :	VAEntrypointVLD
      VAProfileVP9Profile0            :	VAEntrypointEncSliceLP
      VAProfileVP9Profile1            :	VAEntrypointVLD
      VAProfileVP9Profile1            :	VAEntrypointEncSliceLP
      VAProfileVP9Profile2            :	VAEntrypointVLD
      VAProfileVP9Profile2            :	VAEntrypointEncSliceLP
      VAProfileVP9Profile3            :	VAEntrypointVLD
      VAProfileVP9Profile3            :	VAEntrypointEncSliceLP
      VAProfileHEVCMain12             :	VAEntrypointVLD
      VAProfileHEVCMain12             :	VAEntrypointEncSlice
      VAProfileHEVCMain422_10         :	VAEntrypointVLD
      VAProfileHEVCMain422_10         :	VAEntrypointEncSlice
      VAProfileHEVCMain422_12         :	VAEntrypointVLD
      VAProfileHEVCMain422_12         :	VAEntrypointEncSlice
      VAProfileHEVCMain444            :	VAEntrypointVLD
      VAProfileHEVCMain444            :	VAEntrypointEncSliceLP
      VAProfileHEVCMain444_10         :	VAEntrypointVLD
      VAProfileHEVCMain444_10         :	VAEntrypointEncSliceLP
      VAProfileHEVCMain444_12         :	VAEntrypointVLD
      VAProfileHEVCSccMain            :	VAEntrypointVLD
      VAProfileHEVCSccMain            :	VAEntrypointEncSliceLP
      VAProfileHEVCSccMain10          :	VAEntrypointVLD
      VAProfileHEVCSccMain10          :	VAEntrypointEncSliceLP
      VAProfileHEVCSccMain444         :	VAEntrypointVLD
      VAProfileHEVCSccMain444         :	VAEntrypointEncSliceLP
      VAProfileAV1Profile0            :	VAEntrypointVLD
      VAProfileHEVCSccMain444_10      :	VAEntrypointVLD
      VAProfileHEVCSccMain444_10      :	VAEntrypointEncSliceLP

[stolk]

I ran a LIBVA_TRACE on both the working intel deb, and non working canonical snap.

The difference is that the working build creates a config (profile 7) and then a context.

The non working build also creates a config (profile 7) but then makes another config (profile -1) and uses that to create the context with profile -1, and wxh at 0x0 instead of 1920x1088.

working.txt

notworking.txt

The question is why the chromium 105.0.5195.19 will create the second config with VRProfileNone.

[Jexu]

It is no the config causing failure, but the second attrib in vaCreateSurface which takes an unsupported modifier named 'I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC'. Chromium handles an external surface buffer for vpp, @stolk is it possible to set a correcct attrib value that driver supported in caps? @XinfengZhang Or do we need to support all drm_fourcc format in SetExternalSurfaceTileFormat in driver?

[stellawuintel]

Auto Created VSMGWL-57653 for further analysis.

[stolk]

@stolk is it possible to set a correcct attrib value that driver supported in caps?

I've been unable to track where this modifier is introduced.

If I search the chromium r105 code base for it, I only get a hit on the definition, not a hit on its use?

ubuntu@chromium-bld:/usr/src/chromium-105.0.5195.19$ find . -type f -name \*.c\* -exec grep -H I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC {} \; 
ubuntu@chromium-bld:/usr/src/chromium-105.0.5195.19$ find . -type f -name \*.h\* -exec grep -H I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC {} \; 
./third_party/libdrm/src/include/drm/drm_fourcc.h:#define I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS_CC fourcc_mod_code(INTEL, 8)
ubuntu@chromium-bld:/usr/src/chromium-105.0.5195.19$ 

I wonder if one of the chromium build dependencies injected this. I'll do some more investigation into where this modifier originates from. So far, this is unclear to me.

[stolk]

I wonder if one of the chromium build dependencies injected this. I'll do some more investigation into where this modifier originates from. So far, this is unclear to me.

It could be that this modifier is pulled in by mesa?

[vanvugt]

Using modifiers is not a bug in itself, it's the default behaviour to achieve best performance for any given architecture. But if you have multiple components and one of them doesn't support modifiers then they need to be disabled by whoever has created the buffer/surface.

The creator of a buffer may not even be aware they are getting modifiers. It's not something you explicitly request, only something you need to explicitly disable sometimes.

[stolk]

Still trying to track the origin of the modifier, but I did manage to trace the callstack where the modifier is rejected:

MediaLibvaCapsG12::SetExternalSurfaceTileFormat
DdiMediaUtil_AllocateSurface
DdiMediaUtil_CreateSurface
DdiMedia_CreateRenderTarget
DdiMedia_CreateSurfaces2
vaCreateSurfaces
vaCreateSurfaces
media::VaapiWrapper::CreateVASurfaceForPixmap
media::VaapiPictureNativePixmapOzone::Initialize
media::VaapiPictureNativePixmapOzone::Allocate
media::VaapiVideoDecodeAccelerator::AssignPictureBuffers
media::VdaVideoDecoder::ProvidePictureBuffersAsync
...

To do: track origin of this external surface, and find out why chromium r104 does not use the modifier, but chromium r105 does.

[KingRayleigh]

facing the same issue did u find any solution yet??

[cttipton]

I'm facing the same on Arch, I regularly rebuild chromium and validate vaapi decode. Interestingly, even the last known working binary no longer works since some set of software patches in mid to late October.

I wonder if one of the chromium build dependencies injected this. I'll do some more investigation into where this modifier originates from. So far, this is unclear to me.

I have tested rolling back the intel-media-driver, mesa, and a number of wild guesses all with the same result. But as I know this build worked at least on Sept. 26 (built from chromium master Sep 24) I am not lead to believe the modifier is inferred at build time, and also am very curious to find out where it originates.

[stolk]

@cttipton @KingRayleigh What kernel versions are you on? I am seeing this on 5.19.0 linux kernel.

[stolk]

This is fixed by:

• Using chromium r107 instead of r105.
• Adding the command line flag: --disable-features=UseChromeOSDirectVideoDecoder

Using that, I get hardware accelerated H264 decoding, as verified with intel_gpu_top monitor, which shows Video engine as busy.