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

["Xiang, Haihao" <haihao.xiang-at-intel.com@ffmpeg.org>]

On Thu, 2022-07-21 at 23:19 +0100, Mark Thompson wrote:
> 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?

This should be removed. I was considering the driver and ffmpeg were built in
different environments. BTW the new va-api version should be 1.15, I will fix it
in the next version.

> 
> > +    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.
> 

MFXVideoCORE_SetHandle() is still needed after creating a session. here use the
pci id to choose an implementation which can support the given device. 

Thanks
Haihao


> > +
> > +    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".
_______________________________________________
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".