* Removed suppressions for IInferRequest deprecation
* Fixed Windows
* More fixes for Windows
* Fixed compilation on Windows
* Fixed comment in documentatipn
* Fixes for Andorid
* Fixes for old gcc 4.8
* WA for cross-compilations
* Fixed compilation
* Fixed HETERO plugin compilation for old compilers
* Flags
Co-authored-by: lab_ddpqa <lab_ddpqa@intel.com>
* zero-copy (assuming determenistic app-level scheduling) for the multi-device, via "borrowing" the corresponding device-specific blobs and letting the app to implicitly use these
* Optimized Infer Request Scheduling
* remoteblob checks in the conventional SetBlob
* correctly (with status) reporting NOT_IMPLEMENTED
* SetBlob to accomodate for the RemoteBobs
* Tests for remote blobs support via MULTI: creating the shared_test in case the other (closed source) plugins would want to use that (in the private shared_tests instantiations).
Also instantiating the remote blobs tests for the some basic combinations to test the MULTI supports them
* macos compilation (and general plugin platform support) fix
* shuffled files, so that the MULTI tests are now part of the ieFuncTests (and need no separate target). Also brushed the macro that handales the NOT_IMPLEMENTED as bit
* further shuffled files, so that the initial MULTI tests are now part of the IE tests, yet specific instances do need separate targets
* Fixed misprint
* Brushing the code and comments a bit
* further brushing of the ScheduleToWorkerRequest: moving the task execution directly into the loop over devices (avoids pointers and 'else' clause)
* 1) zero-copy (assuming determenistic app-level scheduling) for the multi-device, via "borrowing" the corresponding device-specific blobs and letting the app to implicitly use these
2) Initial MULTI section in the opt guide (primarily to document a tip on helping the MULTI to keep the zero-copy path)
* [MULTI] remote context support and associated scheduling (respecting the remote data affinity)
* fix CentOS (old) gcc issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81880
since the intriduced therad_local string is template the bug manifests itself (and the string is not allocated/initialized).
the QA is to wrap the std::string into the function
* further fix for the old gcc versions issue, now with non-trivial thread_local destruction sefault: switching from the std::string to the plain const char*
* additional tests for the MULTI and remote blobs (no remote context and multi GPUs cases)
* fix for the tests (that now can check for more specific NotImplemented exeption).
Alos couple of line endings
Ilya Lavrenov