Re: [FFmpeg-devel] [PATCH v11 10/13] lavu/hwcontext_qsv: make qsv hwdevice works with oneVPL

From: Mark Thompson <sw@jkqxz.net>
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH v11 10/13] lavu/hwcontext_qsv: make qsv hwdevice works with oneVPL
Date: Thu, 21 Jul 2022 23:19:39 +0100
Message-ID: <8280f7b7-cf39-722a-c189-79af71c22c7c@jkqxz.net> (raw)
In-Reply-To: <20220720084006.5033-11-haihao.xiang@intel.com>

On 20/07/2022 09:40, Xiang, Haihao wrote:
> From: Haihao Xiang <haihao.xiang@intel.com>
> 
> In oneVPL, MFXLoad() and MFXCreateSession() are required to create a
> workable mfx session[1]
> 
> Add config filters for D3D9/D3D11 session (galinart)
> 
> The default device is changed to d3d11va for oneVPL when both d3d11va
> and dxva2 are enabled on Microsoft Windows
> 
> This is in preparation for oneVPL support
> 
> [1] https://spec.oneapi.io/versions/latest/elements/oneVPL/source/programming_guide/VPL_prg_session.html#onevpl-dispatcher
> 
> Co-authored-by: galinart <artem.galin@intel.com>
> Signed-off-by: galinart <artem.galin@intel.com>
> Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
> ---
>   libavutil/hwcontext_qsv.c | 531 +++++++++++++++++++++++++++++++++++---
>   1 file changed, 493 insertions(+), 38 deletions(-)
> 
> diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
> index 21a2a805f8..90b7988dec 100644
> --- a/libavutil/hwcontext_qsv.c
> +++ b/libavutil/hwcontext_qsv.c
> ...
> +
> +static int qsv_va_update_config(void *ctx, mfxHDL handle, mfxConfig cfg)
> +{
> +#if CONFIG_VAAPI
> +#if VA_CHECK_VERSION(1, 5, 0)
> +#define LOCAL_VADISPLAYPCIID VADisplayPCIID
> +#else
> +#define LOCAL_VADISPLAYPCIID 21
> +#endif

This seems to be handling the case where you built the driver against a newer version of libva containing the field but then downgraded it before building ffmpeg?  Who are you expecting to do that?

> +    mfxStatus sts;
> +    VADisplay dpy = handle;
> +    VAStatus vas;
> +    VADisplayAttribute attr = {
> +        .type = LOCAL_VADISPLAYPCIID
> +    };
> +    mfxVariant impl_value;
> +
> +    vas = vaGetDisplayAttributes(dpy, &attr, 1);
> +    if (vas == VA_STATUS_SUCCESS && attr.flags != VA_DISPLAY_ATTRIB_NOT_SUPPORTED) {
> +        impl_value.Type = MFX_VARIANT_TYPE_U16;
> +        impl_value.Data.U16 = (attr.value & 0xFFFF);
> +        sts = MFXSetConfigFilterProperty(cfg,
> +                                         (const mfxU8 *)"mfxExtendedDeviceId.DeviceID", impl_value);
> +        if (sts != MFX_ERR_NONE) {
> +            av_log(ctx, AV_LOG_ERROR, "Error adding a MFX configuration"
> +                   "DeviceID property: %d.\n", sts);
> +            goto fail;
> +        }
> +    } else {
> +        av_log(ctx, AV_LOG_ERROR, "Failed to get device id from the driver. Please "
> +               "consider to upgrade the driver to support VA-API 1.5.0. \n");
> +        goto fail;
> +    }

The use of the PCI ID doesn't make sense to me here?

A PCI ID tells you the type of the device, not which device it was - given that the normal use-case for multiple devices in servers generally has lots of idential ones this does not seem helpful.

> +
> +    return 0;
> +
> +fail:
> +#endif
> +    return AVERROR_UNKNOWN;
> +}
> +
> ...

- Mark
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".