[FFmpeg-devel] [PATCH 1/3] lavu/hwcontext_vaapi: Add a new quirk

[Mark Thompson]

On 28/03/2024 02:17, Xiang, Haihao wrote:
> From: Haihao Xiang <haihao.xiang at intel.com>
> 
> libva2 doesn't require a fixed surface-array any more, but some
> driver/hardware combinations which rely on this are still used. To
> reduce the impact to users, add a quirk for the driver/hardware
> combination which supports dynamic surface pool.
> 
> Signed-off-by: Haihao Xiang <haihao.xiang at intel.com>
> ---
>   libavutil/hwcontext_vaapi.c | 7 +++++++
>   libavutil/hwcontext_vaapi.h | 6 ++++++
>   2 files changed, 13 insertions(+)
> 
> diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
> index 56d03aa4cd..dae5dd4a11 100644
> --- a/libavutil/hwcontext_vaapi.c
> +++ b/libavutil/hwcontext_vaapi.c
> @@ -390,6 +390,13 @@ static const struct {
>           "Splitted-Desktop Systems VDPAU backend for VA-API",
>           AV_VAAPI_DRIVER_QUIRK_SURFACE_ATTRIBUTES,
>       },
> +#if CONFIG_VAAPI_1
> +    {
> +        "New Intel iHD",
> +        "Intel iHD driver for Intel(R) Gen Graphics",
> +        AV_VAAPI_DRIVER_QUIRK_DYNAMIC_SURFACE_POOL,
> +    },
> +#endif
>   };
>   
>   static int vaapi_device_init(AVHWDeviceContext *hwdev)
> diff --git a/libavutil/hwcontext_vaapi.h b/libavutil/hwcontext_vaapi.h
> index 0b2e071cb3..07014fd526 100644
> --- a/libavutil/hwcontext_vaapi.h
> +++ b/libavutil/hwcontext_vaapi.h
> @@ -58,6 +58,12 @@ enum {
>        * and the results of the vaQuerySurfaceAttributes() call will be faked.
>        */
>       AV_VAAPI_DRIVER_QUIRK_SURFACE_ATTRIBUTES = (1 << 3),
> +
> +    /**
> +     * The driver (and the underlying HW) supports dynamic surface pool.
> +     * The vaCreateContext() call doesn't require a fixed surface-array.
> +     */
> +    AV_VAAPI_DRIVER_QUIRK_DYNAMIC_SURFACE_POOL = (1 << 4),
>   };
>   
>   /**

I do not think a vendor-specific quirk like this is a reasonable answer, but I can see that your company is invested in making sure that your current driver doesn't hit this problem.

Given that, I give up on arguing for trying to preserve compatibility here.  Let's just use dynamic pools unconditionally and see if anything breaks.

Is there any reason not to drop support for libva < 2.0 at the same time?  (Making CONFIG_VAAPI_1 always true.)  It is of similar age to C17, which we are intending to require soon as well.

Thanks,

- Mark