[FFmpeg-devel] [PATCH v10 10/13] lavu/hwcontext_qsv: make qsv hwdevice works with oneVPL
From: Haihao Xiang 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 Signed-off-by: galinart Signed-off-by: Haihao Xiang --- libavutil/hwcontext_qsv.c | 530 +++--- 1 file changed, 492 insertions(+), 38 deletions(-) diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c index 21a2a805f8..9b0c255cf4 100644 --- a/libavutil/hwcontext_qsv.c +++ b/libavutil/hwcontext_qsv.c @@ -49,6 +49,7 @@ #include "pixdesc.h" #include "time.h" #include "imgutils.h" +#include "avassert.h" #define QSV_VERSION_ATLEAST(MAJOR, MINOR) \ (MFX_VERSION_MAJOR > (MAJOR) || \ @@ -58,6 +59,12 @@ #define QSV_ONEVPL QSV_VERSION_ATLEAST(2, 0) #define QSV_HAVE_OPAQUE !QSV_ONEVPL +#if QSV_ONEVPL +#include +#else +#define MFXUnload(a) do { } while(0) +#endif + typedef struct QSVDevicePriv { AVBufferRef *child_device_ctx; } QSVDevicePriv; @@ -619,6 +626,435 @@ static mfxStatus frame_get_hdl(mfxHDL pthis, mfxMemId mid, mfxHDL *hdl) return MFX_ERR_NONE; } +#if QSV_ONEVPL + +static int qsv_d3d11_update_config(void *ctx, mfxHDL handle, mfxConfig cfg) +{ +#if CONFIG_D3D11VA +mfxStatus sts; +IDXGIAdapter *pDXGIAdapter; +DXGI_ADAPTER_DESC adapterDesc; +IDXGIDevice *pDXGIDevice = NULL; +HRESULT hr; +ID3D11Device *device = handle; +mfxVariant impl_value; + +hr = ID3D11Device_QueryInterface(device, &IID_IDXGIDevice, (void**)&pDXGIDevice); +if (SUCCEEDED(hr)) { +hr = IDXGIDevice_GetAdapter(pDXGIDevice, &pDXGIAdapter); +if (FAILED(hr)) { +av_log(ctx, AV_LOG_ERROR, "Error IDXGIDevice_GetAdapter %d\n", hr); +goto fail; +} + +hr = IDXGIAdapter_GetDesc(pDXGIAdapter, &adapterDesc); +if (FAILED(hr)) { +av_log(ctx, AV_LOG_ERROR, "Error IDXGIAdapter_GetDesc %d\n", hr); +goto fail; +} +} else { +av_log(ctx, AV_LOG_ERROR, "Error ID3D11Device_QueryInterface %d\n", hr); +goto fail; +} + +impl_value.Type = MFX_VARIANT_TYPE_U16; +impl_value.Data.U16 = adapterDesc.DeviceId; +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; +} + +impl_value.Type = MFX_VARIANT_TYPE_PTR; +impl_value.Data.Ptr = &adapterDesc.AdapterLuid; +sts = MFXSetConfigFilterProperty(cfg, + (const mfxU8 *)"mfxExtendedDeviceId.DeviceLUID", impl_value); +if (sts != MFX_ERR_NONE) { +av_log(ctx, AV_LOG_ERROR, "Error adding a MFX configuration" + "DeviceLUID property: %d.\n", sts); +goto fail; +} + +impl_value.Type = MFX_VARIANT_TYPE_U32; +impl_value.Data.U32 = 0x0001; +sts = MFXSetConfigFilterProperty(cfg, + (const mfxU8 *)"mfxExtendedDeviceId.LUIDDeviceNodeMask", impl_value); +if (sts != MFX_ERR_NONE) { +av_log(ctx, AV_LOG_ERROR, "Error adding a MFX configuration" + "LUIDDeviceNodeMask property: %d.\n", sts); +goto fail; +} + +return 0; + +fail: +#endif +return AVERROR_UNKNOWN; +} + +static int qsv_d3d9_update_config(void *ctx, mfxHDL handle, mfxConfig cfg) +{ +int ret = AVERROR_UNKNOWN; +#if CONFIG_DXVA2 +mfxStatus sts; +IDirect3DDeviceManager9* devmgr = handle; +IDirect3DDevice9Ex *device = NULL; +HANDLE device_handle = 0; +IDirect3D9Ex *d3d9ex = NULL; +LUID luid; +D3DDEVICE_CREATION_PARAMETERS params; +HRESULT hr; +mfxVariant impl_value; + +hr = IDirect3DDeviceManager9_OpenDeviceHandle(devmgr, &device_handle); +if (FAILED(hr)) { +av_log(ctx, AV_LOG_ERROR, "Error OpenDeviceHandle %d\n", hr); +goto fail; +} + +hr = IDirect3DDeviceManager9_LockDevice(devmgr, device_handle, &device, TRUE); +if (FAILED(hr)) { +av_log(ctx, AV_LOG_ERROR, "Error LockDevice %d\n", hr); +goto fail; +} + +hr = IDirect3DDevice9Ex_GetCreationParameters(device, ¶ms); +if (FAILED(hr)) { +av_log(ctx, AV_LOG_ERROR, "Error IDirect3DDevice9_GetCreationParameters %d\n", hr); +goto unlock; +} + +hr = IDirect3DDevice9Ex_GetDirect3D(device, &d3d9ex); +if (FAILED(hr)) { +av_log(ctx, AV_LOG_ERROR, "Error IDirect3DDevice9Ex_GetAdapterLUID %d\n", hr); +goto unlock; +} + +hr = IDirect3D9Ex_GetAd
Re: [FFmpeg-devel] [PATCH v10 10/13] lavu/hwcontext_qsv: make qsv hwdevice works with oneVPL
Quoting Xiang, Haihao (2022-07-12 08:27:32) > +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 > +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 & 0x); > +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_WARNING, "Cannot get device id from the driver, > the default " > + "MFX implementation will be loaded for this device. Please > consider to " > + "upgrade the driver to support VAAPI 1.5.0. \n"); I would still prefer to fail here. The user requested a specific device, disregarding that request is evil. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v10 10/13] lavu/hwcontext_qsv: make qsv hwdevice works with oneVPL
On Mon, 2022-07-18 at 15:02 +0200, Anton Khirnov wrote: > Quoting Xiang, Haihao (2022-07-12 08:27:32) > > +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 > > +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 & 0x); > > +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_WARNING, "Cannot get device id from the driver, > > the default " > > + "MFX implementation will be loaded for this device. Please > > consider to " > > + "upgrade the driver to support VAAPI 1.5.0. \n"); > > I would still prefer to fail here. The user requested a specific device, > disregarding that request is evil. Thanks for the comment. There is only one available device for most users, so the default one and the given one from user should be the same, otherwise it won't work. I don't want to make them in trouble if they don't have a driver to support the new interface. However I agree with you it is a little evil to ignore the request. I'll update the patch to return error here. Regards Haihao ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v10 10/13] lavu/hwcontext_qsv: make qsv hwdevice works with oneVPL
On Tue, 2022-07-19 at 07:18 +, Xiang, Haihao wrote: > On Mon, 2022-07-18 at 15:02 +0200, Anton Khirnov wrote: > > Quoting Xiang, Haihao (2022-07-12 08:27:32) > > > +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 > > > +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 & 0x); > > > +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_WARNING, "Cannot get device id from the > > > driver, > > > the default " > > > + "MFX implementation will be loaded for this device. Please > > > consider to " > > > + "upgrade the driver to support VAAPI 1.5.0. \n"); > > > > I would still prefer to fail here. The user requested a specific device, > > disregarding that request is evil. > > Thanks for the comment. There is only one available device for most users, so > the default one and the given one from user should be the same, otherwise it > won't work. I don't want to make them in trouble if they don't have a driver > to > support the new interface. However I agree with you it is a little evil to > ignore the request. I'll update the patch to return error here. > Fixed in v11, Thanks Haihao ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v10 10/13] lavu/hwcontext_qsv: make qsv hwdevice works with oneVPL
> -Original Message- > From: ffmpeg-devel On Behalf Of > Xiang, Haihao > Sent: Tuesday, July 19, 2022 9:19 AM > To: an...@khirnov.net; ffmpeg-devel@ffmpeg.org > Cc: Galin, Artem > Subject: Re: [FFmpeg-devel] [PATCH v10 10/13] lavu/hwcontext_qsv: > make qsv hwdevice works with oneVPL > > On Mon, 2022-07-18 at 15:02 +0200, Anton Khirnov wrote: > > Quoting Xiang, Haihao (2022-07-12 08:27:32) > > > +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 > > > +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 & 0x); > > > +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_WARNING, "Cannot get device id from > the driver, > > > the default " > > > + "MFX implementation will be loaded for this > device. Please > > > consider to " > > > + "upgrade the driver to support VAAPI 1.5.0. \n"); > > > > I would still prefer to fail here. The user requested a specific > device, > > disregarding that request is evil. > > Thanks for the comment. There is only one available device for most > users, so > the default one and the given one from user should be the same, > otherwise it > won't work. I don't want to make them in trouble if they don't have a > driver to > support the new interface. However I agree with you it is a little > evil to > ignore the request. I'll update the patch to return error here. I'm not a fan of that kind of automagic behavior. Quick success experiences are surely desirable in general, but we also need to consider the effects of such behavior - in this case, that would mean: It doesn't really matter what a user specifies for the parameter, because it will always work anyway. In turn, users may start to think that their wrong command with the wrong ID would be right, and then, in a subsequent command use that wrong ID again in different context, where it might fail, while in turn maximizing confusion. When it is possible to internally retrieve potentially valid values, why not output something useful like: "XXID failed, you might want to try A, B or C" (or similar)? Kind regards, softworkz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v10 10/13] lavu/hwcontext_qsv: make qsv hwdevice works with oneVPL
On Thu, 2022-07-21 at 20:30 +, Soft Works wrote: > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > Xiang, Haihao > > Sent: Tuesday, July 19, 2022 9:19 AM > > To: an...@khirnov.net; ffmpeg-devel@ffmpeg.org > > Cc: Galin, Artem > > Subject: Re: [FFmpeg-devel] [PATCH v10 10/13] lavu/hwcontext_qsv: > > make qsv hwdevice works with oneVPL > > > > On Mon, 2022-07-18 at 15:02 +0200, Anton Khirnov wrote: > > > Quoting Xiang, Haihao (2022-07-12 08:27:32) > > > > +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 > > > > +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 & 0x); > > > > +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_WARNING, "Cannot get device id from > > > > the driver, > > > > the default " > > > > + "MFX implementation will be loaded for this > > > > device. Please > > > > consider to " > > > > + "upgrade the driver to support VAAPI 1.5.0. \n"); > > > > > > I would still prefer to fail here. The user requested a specific > > > > device, > > > disregarding that request is evil. > > > > Thanks for the comment. There is only one available device for most > > users, so > > the default one and the given one from user should be the same, > > otherwise it > > won't work. I don't want to make them in trouble if they don't have a > > driver to > > support the new interface. However I agree with you it is a little > > evil to > > ignore the request. I'll update the patch to return error here. > > I'm not a fan of that kind of automagic behavior. Quick success > experiences are surely desirable in general, but we also need to > consider the effects of such behavior - in this case, that would > mean: It doesn't really matter what a user specifies for the parameter, > because it will always work anyway. > > In turn, users may start to think that their wrong command with the > wrong ID would be right, and then, in a subsequent command > use that wrong ID again in different context, where it might fail, > while in turn maximizing confusion. > > When it is possible to internally retrieve potentially valid > values, why not output something useful like: "XXID failed, you > might want to try A, B or C" (or similar)? Agree, and this is fixed in the new version. Thanks Haihao ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".