G-API: oneVPL - Implement IDeviceSelector & default cfg_param-based selector#20738
G-API: oneVPL - Implement IDeviceSelector & default cfg_param-based selector#20738alalek merged 15 commits intoopencv:masterfrom
Conversation
fef0fed to
fb18751
Compare
modules/gapi/include/opencv2/gapi/streaming/onevpl/device_selector_interface.hpp
Outdated
Show resolved
Hide resolved
modules/gapi/src/streaming/onevpl/cfg_param_device_selector.cpp
Outdated
Show resolved
Hide resolved
| GAPI_LOG_DEBUG(nullptr, "Add HW acceleration support"); | ||
| mfxVariant accel_mode = cfg_param_to_mfx_variant(*accel_mode_it); | ||
|
|
||
| switch(accel_mode.Data.U32) { |
There was a problem hiding this comment.
mfxVariant Data is an c-like union. each configuration parameter specifically fills its defined type in union and mfxImplDescription.AccelerationMode has U32 type value
There was a problem hiding this comment.
so why do we handle only that case?
There was a problem hiding this comment.
because accel_mode.Data is c-union, and only one member U32 is correct for the value determined by "mfxImplDescription.AccelerationMode" description
let's look at this as std::variant<...> and as VPL mentioned in their Docs, value of type of mfxImplDescription.AccelerationMode should be stored as U32.
modules/gapi/src/streaming/onevpl/cfg_param_device_selector.cpp
Outdated
Show resolved
Hide resolved
| } | ||
| mfxVariant accel_mode = cfg_param_to_mfx_variant(*accel_mode_it); | ||
|
|
||
| switch(accel_mode.Data.U32) { |
There was a problem hiding this comment.
this case is handled in previous constuctor, too - should that logic be unified?
There was a problem hiding this comment.
the first ctor uses device creation from default adapter - no external pointers from user
but this ctor just wrap user-created device passed by void* pointer AND uses actual device type through CfgParams to restore type and work out some checks
modules/gapi/src/streaming/onevpl/cfg_param_device_selector.hpp
Outdated
Show resolved
Hide resolved
| } | ||
| } | ||
| } // namespace opencv_test | ||
| #endif // HAVE_ONEVPL |
There was a problem hiding this comment.
Should the full test bodies be enclosed under HAVE_ macros?
There was a problem hiding this comment.
..or the idea is to extend this with other flags as they arrive?
I'd prefer different tests cover different cases otherwise you can't say for sure what actually passed/failed in the test looking at its name when it has that lots of compile conditionals inside
There was a problem hiding this comment.
Do you mean
TEST(OneVPL_Source_Device_Selector_CfgParam, PtrDeviceFromCfgParam)
then
TEST(OneVPL_Source_Device_Selector_CfgParam, DX11_PtrDeviceFromCfgParam)
then
TEST(OneVPL_Source_Device_Selector_CfgParam, YYY_PtrDeviceFromCfgParam)
agree, it makes sense
modules/gapi/include/opencv2/gapi/streaming/onevpl/device_selector_interface.hpp
Outdated
Show resolved
Hide resolved
modules/gapi/include/opencv2/gapi/streaming/onevpl/device_selector_interface.hpp
Show resolved
Hide resolved
modules/gapi/include/opencv2/gapi/streaming/onevpl/device_selector_interface.hpp
Show resolved
Hide resolved
modules/gapi/include/opencv2/gapi/streaming/onevpl/device_selector_interface.hpp
Show resolved
Hide resolved
modules/gapi/include/opencv2/gapi/streaming/onevpl/device_selector_interface.hpp
Show resolved
Hide resolved
modules/gapi/src/streaming/onevpl/cfg_param_device_selector.cpp
Outdated
Show resolved
Hide resolved
modules/gapi/src/streaming/onevpl/cfg_param_device_selector.hpp
Outdated
Show resolved
Hide resolved
modules/gapi/src/streaming/onevpl/device_selector_interface.cpp
Outdated
Show resolved
Hide resolved
de615ce to
323d81d
Compare
92d3e84 to
2dddeaf
Compare
|
@alalek could you merge it please? |
|
There is build regression caused by this patch: http://pullrequest.opencv.org/buildbot/builders/master_openvino-opencl-win64/builds/608 (used machine has minimal setup of "MSVS Build Tools 2019") |
|
ok, I will try to make a patch |
|
added PR #20921 |
…v_select G-API: oneVPL - Implement IDeviceSelector & default cfg_param-based selector * Initial commit * Add MACRO undef * Change IDeviceSelector, Change Inf sample for choose external device * Fix compilation * Address some comments * Fix compilation * Add missing header * Add EXPORT to dev selector * Add guard * Remove enum type attr * Fix compilation without VPL * Add HAVE_INFER guard in sample * Remove unusable include from tests * Remove unusable include from sample * Remove cl_d3d11 header from unit test
Designed
IDeviceSelectorallows user to provide some customization in selection of GPU/Accel device when set uponevpl::Sourceobject. In future is allow to support some hybrid-pipeline when several devices selected as decode/vpp accelerationAt the moment
CfgParamDeviceSelectoris implementingIDeviceSelectorand supporting either default device selection or externally provided DX11 device as VPL source acceleratorExample of Integration with inference high-level scenario
Pull Request Readiness Checklist
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
Patch to opencv_extra has the same branch name.
Build configuration