openvino: Compile-time fallback for missing plugins.xml
Hello,
we recently started using OpenVINO as a backend for OpenCV’s DNN module. As we only need a relatively small selection of features for this purpose (only the Intel CPU plugin as well as the Inference Engine frontend), we compiled OpenVINO ourselves. We prefer using OpenVINO as shared libraries and everything works fine. Still, the shared libraries depend on the plugins.xml configuration file at runtime. As this is redundant here - the desired configuration is already known at compile time - but also yields a runtime error if missing, we would like to propose to add a compile-time fallback for a missing plugins.xml, similar to the static library case.
By investigating how the plugin registration works in the static library case, we found the getStaticPluginsRegistry() function in ie_plugins.hpp that is generated by the plugins.cmake script. Here, we think that similarly generating the file by CMake should also be possible in the dynamic library case such that while calling Core::Core() in ie_core.cpp, similar code as in the function getStaticPluginsRegistry() could be used as a fallback if plugins.xml is missing at runtime.
Generally, we are open to modify the CMake or source code files accordingly. However, before programming anything we would like to discuss this idea first. So what do you think? Do you agree that this might be useful feature or does it even conflicts with your plans?
Thanks for your time!
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 1
- Comments: 31 (31 by maintainers)
Yes correct, my fault. I agree that this logic should work in your PR.
For the moment only regarding your comment to the first point, we’re coming back to the others later but maybe you could verify this in between already: In
register_compile_time_plugins()we already implemented thepluginRegistry.find(deviceName) == pluginRegistry.end()check before adding it, i.e. if theplugins.xmlis used to load the plugin, it will be skipped here such that the xml-based path overrules the compiled-in ones. Or did we miss anything here?