* Try to improve gflags
* Try to improve gflags: part 2
* Tried to use dependencies on system
* Use nlohmann_jsonConfig from system
* Enabled nlohmann_json from system
* Improvements
* handle system gflags in developer package
* Simplifications
* Simplify dependency management
* Corrected package names
* Fixed subgraphsDumper configure stage
* Try to fix rhel8
* Try to fix macosx
* Fixed VPUX build
* Fixed aliasing issues
* Suppress some wanrings
* export gflags when build it
* Fixed some LTO
* Try to fix Mac
* revert
* use gflags as private dependency
* Aligned targets in developer package
* Fixed frontends tests build on U20 with LTO
* PAssed
* Don't use pkg_search_module(zlib ..) during cross-compilation
* Removed unused variables
* Fixed finding of zlib during cross-compilation
* CVS-83529
* Use nothreads_static
* Fixed python
* Try to improve gflags
* Try to improve gflags: part 2
* Tried to use dependencies on system
* Use nlohmann_jsonConfig from system
* Enabled nlohmann_json from system
* Improvements
* handle system gflags in developer package
* Simplifications
* Simplify dependency management
* Corrected package names
* Fixed subgraphsDumper configure stage
* Try to fix rhel8
* Try to fix macosx
* Fixed VPUX build
* Fixed aliasing issues
* Suppress some wanrings
* export gflags when build it
* Fixed some LTO
* Try to fix Mac
* revert
* use gflags as private dependency
* Aligned targets in developer package
* Fixed frontends tests build on U20 with LTO
* PAssed
* Don't use pkg_search_module(zlib ..) during cross-compilation
* Removed unused variables
* Fixed finding of zlib during cross-compilation
* [Python API] Remove old api class from the new api
* start working on refactoring of OVAny
* fix tests
* fix code-style
* remove tuple test
* fix test
* fix omz hash
* one more overload
* fix pyfloat
* move from_ov_any to utils
* code-style
* move function from common to utils
* Improve performance for 'ov::Model::add_output'
On first call of `add_output(tensor_name)` all available tensor names are cached.
Next calls take nodes from cache which significantly reduces complexity.
Cache is invalidated if topological cache is not valid or cache points to incorrect output (no tensor name of this node anymore)
The same caching is done for 'add_output(op_name, output_index)'
Tests:
- Verifies that adding outputs to all nodes has linear complexity O(N), not O(N^2)
- Verifies cache invalidation scenarios
* Fix python tests
* Update topological cache after add_output(Output<Node>) by adding result to the end of cached ops
* Add 'm_shared_rt_info' to 'result node just for consistency (there is actually no scenario which may fail due to absence of this info for Result
* Added test cases to verify that names cache should be cleared on refresh of 'get_ordered_ops'
* Performance improvement for constant creation
The issue is that 'are_all_data_elements_bitwise_identical()' is called every time in Constant constructor, and it potentially checks all buffer which is O(N) complexity.
While it is needed only if client uses 'get_all_data_elements_bitwise_identical'
Solution:
- Defer calculation until first call of 'get_all_data_elements_bitwise_identical'
- Store calculated value in mutable class member to reuse it on next calls of 'get_all_data_elements_bitwise_identical'
Test verifies both cases:
a) that constant creation with shared memory data (now O(1)) is significantly faster than creation+bitwiseCheck O(N)
b) Than once calculated, value is taken from cache, which is significantly faster than re-calculation
* fix clang-format
* Stash - Linux implementation
* Windows mmap implementation + unicode
* Clang for windows
* removed debug print
* Add handling of empty bin file
* fix windows includes
* Fix python test
* Unit tests
Fix for Constant with size > 4GB
* Fix review comments
* InputTensorInfo::from implementation
If user's application already has `ov::runtime::Tensor` object created,
it will be possible to reuse basic characteristics for input (shape, precision) from tensor using InputTensorInfo::from method
* Rename 'from' to 'set_from' as in Python 'from' keyword is used for import modules
Python bindings: from ov.Tensor and from numpy array
* Style fix (quotes)
* Apply suggestions from code review
Co-authored-by: Ilya Churaev <ilyachur@gmail.com>
* Fix code style
* Use set_from in hello_classification CPP sample
Co-authored-by: Ilya Churaev <ilyachur@gmail.com>
* Fix in Preprocessing python bindings - add correct default arguments for:
- PreProcessSteps::convert_element_type
- PostProcessSteps::convert_element_type
- InputTensorInfo::set_color_format
Otherwise, python users must always specify optional params
E.g. instead of writing `tensor().set_color_format(ColorFormat.RGB)` python users will have to write `tensor().set_color_format(ColorFormat.RGB, [])`
* Corrected 'help' output
* Exposing 'openvino.runtime.Type.undefined' and use it in 'convert_element_type' documentation
* Fixed Apple install
* Update path to libs in setupvars.sh
* Fix IE_CPACK_RUNTIME_PATH for Apple
* Fix wheels packaging
Co-authored-by: Alexey Suhov <alexey.suhov@intel.com>
* Checking compatibility between 'pyopenvino' and 'libopenvino' on 'import phase'
This fix is to prevent undefined behavior when user loads OpenVINO from python, but pyopenvino loads different version of 'libopenvino'
This may happen if user has several releases installed and played around PATH/PYTHONPATH environment variables.
In such case, user may have undefined behavior - application may crash in the middle of the usage or use incorrect release.
Fix checks build versions for pyopenvino and ov::get_openvino_version. If mismatch occurs, exception is thrown.
This logic is disabled if user has built OpenVINO locally, experienced developers probably know what they're doing, so if version has 'custom_' prefix - this logic is disabled
* Removed custom logic for CI_BUILD_NUMBER, it is reused from already included version.cmake
* Use addVersionDefines macro