- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I've built 2024.1.0 manually for our embedded Linux platform, which runs 5.15.21 with RT support. It is a custom build based on the OpenVino Linux build instructions. I've added most of the thirdparty packages into that directory, though not all, with the assumption that just dropping them into the thirdparty directory means OpenVino will use them as needed. The build completes successfully and I've deployed to /opt/openvino. I've set LD_LIBRARY_PATH to include /opt/openvino/lib, where I've placed all the libraries from the build. All libraries are found for hello_query_device on the target:
$ ldd /opt/openvino/bin/hello_query_device
linux-vdso.so.1 (0x00007ffd7cfd3000)
libopenvino.so.2410 => /opt/openvino/lib/libopenvino.so.2410 (0x00007f972b209000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f972b027000)
libm.so.6 => /lib64/libm.so.6 (0x00007f972aee4000)
libssp.so.0 => /lib64/libssp.so.0 (0x00007f972aedf000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f972aec5000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f972aea5000)
libc.so.6 => /lib64/libc.so.6 (0x00007f972ace3000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f972acde000)
/lib64/ld-linux-x86-64.so.2 (0x00007f972c490000)
But no devices are found when I run the sample program.
$ /opt/openvino/bin/hello_query_device
[ INFO ] Build ................................. 2024.1.0-8998-0b89bf8eebf-feature/QSYSDEV-35209
[ INFO ]
[ INFO ] Available devices:
Have I missed a dependency? We last built from 2022.1.0 but that build was very different, so I'm thinking I missed some dependency that I can't identify. I'm just doing the build and don't actually use OpenVino (our devs are linking their C++ to it) so if I missed something obvious let me know. Thanks.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Mjhammel,
Thank you for reaching out to us.
To investigate further, could you provide us with the additional details below:
OS version :
CPU / GPU details :
Steps and additional configuration when you Build OpenVINO™ Runtime for Linux :
On the other hand, does the sample show any error messages or only shows no available devices? We suggest you try to enable plugins build for the CPU (ENABLE_INTEL_CPU) or GPU (ENABLE_INTEL_GPU) to see if this solves the issue. However, it should already be enabled if you are using x86 platforms.
Regards,
Megat
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sure thing, Megat. Here they are.
OS version: completely custom build, not based on any desktop/server distro and not based on Buildroot, Yocto, OpenEmbedded build system. Linux version is 5.15.21 with RT extensions.
CPU/GPU Details: Currently testing the build on Apollo Lake Atom and Elkhart Lake Atom.
Build steps.
- Build and install to staging tree both xbyak and oneTBB
- Unpack plugins to respective directories under OpenVino/thirdparty:
- pugixml
- gflags
- protobuf
- flatbuffers
- snappy
- onnx
- json
- zlib
- Build OpenVino using a custom Makefile target.
cd $$@/build && \
export TBBROOT=$($1_ARCH)/oneTBB-install/opt/openvino/ && \
cmake -DCMAKE_BUILD_TYPE=Release \
-DCMAKE_TOOLCHAIN_FILE=$(LOCAL_TOOLS)/bin/$($1_ARCH).cmake \
-DOPENCL_VENDOR_PATH=/opt/openvino/etc/OpenCL/vendors \
-DCMAKE_INSTALL_PREFIX=/opt/openvino \
-DCMAKE_COLOR_MAKEFILE=OFF \
-DENABLE_CPP_API=ON \
-DCMAKE_VERBOSE_MAKEFILE=ON \
-DTBB_BUILD=OFF \
-DUSE_SYSTEM_TBB=ON \
-DTBBMALLOC_BUILD=OFF \
-DTHREADING=TBB \
-DENABLE_INTEL_CPU=ON \
-DENABLE_INTEL_GPU=ON \
-DENABLE_SYSTEM_OPENCL=OFF \
-DENABLE_PYTHON=OFF \
CFLAGS="-fstack-protector-all -I$($1_INSTALL)/opt/openvino/include" \
LDFLAGS="-L$($1_INSTALL)/opt/openvino/lib,-L$($1_INSTALL)/usr/lib -lpthread" \
..
cd $$@/build && cmake --build . --parallel $(SIMUL)
make -C $$@/build DESTDIR="../../openvino-install/" install
DESTDIR is used to create a tarball package used in a separate build process for the root file system. Installation on the target is to /opt/openvino. I do not install the setvars.sh script. Previously I installed a custom version of that but haven't on this build yet.
I believe I've enabled what I need based on the plugins, but again, I may be missing something.
I was told this morning that the python hello_query_devices script DOES report CPU/GPU information. However, we don't use python on the target platforms so that's not an option for us.
Thanks again for your help Megat.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
One other thing: Although the build host is x86_64, this is built using an x86_64 cross compiler because our primary tree is built for several different architectures, though OpenVino is just being built for x86_64.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Mjhammel,
Thank you for the information provided.
We are currently investigating this issue and will provide an update soon. For your information, I build OpenVINO™ 2024.1.0 from source using the same CMake configuration, but with the default third-party packages, and I was able to run the C++ Hello Query Sample.
./hello_query_device
[ INFO ] Build ................................. 2024.1.0-15008-f4afc983258
[ INFO ]
[ INFO ] Available devices:
[ INFO ] CPU
[ INFO ] SUPPORTED_PROPERTIES:
[ INFO ] Immutable: AVAILABLE_DEVICES : ""
[ INFO ] Immutable: RANGE_FOR_ASYNC_INFER_REQUESTS : 1 1 1
[ INFO ] Immutable: RANGE_FOR_STREAMS : 1 1
[ INFO ] Immutable: EXECUTION_DEVICES : CPU
[ INFO ] Immutable: FULL_DEVICE_NAME : Intel(R) Atom(TM) Processor E3950 @ 1.60GHz
[ INFO ] Immutable: OPTIMIZATION_CAPABILITIES : FP32 FP16 INT8 BIN EXPORT_IMPORT
[ INFO ] Immutable: DEVICE_TYPE : integrated
[ INFO ] Immutable: DEVICE_ARCHITECTURE : intel64
[ INFO ] Mutable: NUM_STREAMS : 1
[ INFO ] Mutable: AFFINITY : CORE
[ INFO ] Mutable: INFERENCE_NUM_THREADS : 0
[ INFO ] Mutable: PERF_COUNT : NO
[ INFO ] Mutable: INFERENCE_PRECISION_HINT : f32
[ INFO ] Mutable: PERFORMANCE_HINT : LATENCY
[ INFO ] Mutable: EXECUTION_MODE_HINT : PERFORMANCE
[ INFO ] Mutable: PERFORMANCE_HINT_NUM_REQUESTS : 0
[ INFO ] Mutable: ENABLE_CPU_PINNING : YES
[ INFO ] Mutable: SCHEDULING_CORE_TYPE : ANY_CORE
[ INFO ] Mutable: MODEL_DISTRIBUTION_POLICY : ""
[ INFO ] Mutable: ENABLE_HYPER_THREADING : YES
[ INFO ] Mutable: DEVICE_ID : ""
[ INFO ] Mutable: CPU_DENORMALS_OPTIMIZATION : NO
[ INFO ] Mutable: LOG_LEVEL : LOG_NONE
[ INFO ] Mutable: CPU_SPARSE_WEIGHTS_DECOMPRESSION_RATE : 1
[ INFO ] Mutable: DYNAMIC_QUANTIZATION_GROUP_SIZE : 0
[ INFO ] Mutable: KV_CACHE_PRECISION : f16
[ INFO ]
Regards,
Megat
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can you describe what you mean by "default third-party packages"? Does that mean you don't add any source for those packages to the thirdparty directory? I can try that that, although I think I've done that previously with the same result.
Does OpenCV play a part if GPU/GPU identification? What code is responsible for finding that information? Maybe I can track down a missing library or maybe the LD_LIBRARY_PATH is not setup correctly.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Mjhammel,
Apologies for the delay.
Yes, I did not add to the openvino/thirdparty directory and I left the directory the same as in the OpenVINO™ GitHub https://github.com/openvinotoolkit/openvino/tree/2024.1.0/thirdparty page. For further clarification, I provided the full steps that I used below. Some differences in my steps are I did not use the DCMAKE_TOOLCHAIN_FILE argument and I ran the command individually instead of using Makefile.
Build Steps:
1 git clone https://github.com/openvinotoolkit/openvino.git -b 2024.1.0
cd openvino
git submodule update --init --recursive
2. chmod +x install_build_dependencies.sh
sudo ./install_build_dependencies.sh
3. mkdir build && cd build
4. export TBBROOT=/home/user/intel/oneapi/tbb/
5. cmake -DCMAKE_BUILD_TYPE=Release \
-DOPENCL_VENDOR_PATH=/etc/OpenCL/vendors \
-DCMAKE_INSTALL_PREFIX=/home/user/2410/ov \
-DCMAKE_COLOR_MAKEFILE=OFF \
-DENABLE_CPP_API=ON \
-DCMAKE_VERBOSE_MAKEFILE=ON \
-DTBB_BUILD=OFF \
-DUSE_SYSTEM_TBB=ON \
-DTBBMALLOC_BUILD=OFF \
-DTHREADING=TBB \
-DENABLE_INTEL_CPU=ON \
-DENABLE_INTEL_GPU=ON \
-DENABLE_SYSTEM_OPENCL=OFF \
-DENABLE_PYTHON=OFF ..
6. cmake --build . --parallel 4
make install
7. cd /home/user/2410/ov/samples/cpp
./build_samples.sh
8. cd /home/user/openvino_cpp_samples_build/intel64/Release
./hello_query_device
Could you try to see if this method for building OpenVINO™ works for you? Do let us know of any issues you face.
On the other hand, OpenCV is not required to run OpenVINO inference as It is an optional dependency that can be used for computer vision alongside OpenVINO™.
For your information, the code responsible for finding the available devices In the C++ Hello Query Sample is the get_available_devices() method from the OpenVINO™ Inference C++ API.
Regards,
Megat
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sorry for the late response - I was on vacation.
The first primary difference is that I use a release tarball. This does not contain the submodules you get when working from the git repo with the submodules update command. I'm guessing that's one problem. This is what happens when you update the submodules from git.
$ git submodule update --init --recursive
Submodule 'src/plugins/intel_npu/thirdparty/level-zero' (https://github.com/oneapi-src/level-zero.git) registered for path 'src/plugins/intel_npu/thirdparty/level-zero'
Submodule 'src/plugins/intel_npu/thirdparty/level-zero-ext' (https://github.com/intel/level-zero-npu-extensions.git) registered for path 'src/plugins/intel_npu/thirdparty/level-zero-ext'
Cloning into '/home4/work/openvino/git/src/plugins/intel_npu/thirdparty/level-zero'...
Cloning into '/home4/work/openvino/git/src/plugins/intel_npu/thirdparty/level-zero-ext'...
Submodule path 'src/plugins/intel_cpu/thirdparty/ComputeLibrary': checked out 'f2eda6665c12d568e179f5b0e7a24ccdc0ac824d'
Submodule path 'src/plugins/intel_cpu/thirdparty/onednn': checked out '26633ae49edd4353a29b7170d9fcef6b2d79f4b3'
Submodule path 'src/plugins/intel_gpu/thirdparty/onednn_gpu': checked out '4e6ff043c439652fcf6c400ac4e0c81bbac7c71c'
Submodule path 'src/plugins/intel_npu/thirdparty/level-zero': checked out '4ed13f327d3389285592edcf7598ec3cb2bc712e'
Submodule path 'src/plugins/intel_npu/thirdparty/level-zero-ext': checked out '0e1c471356a724ef6d176ba027a68e210d90939e'
Submodule path 'thirdparty/gtest/gtest': checked out '70a225df5dd55bd5931664fadaa67765eb9f6016'
Submodule path 'thirdparty/open_model_zoo': checked out 'cf5141dad2a4f24e1c5d5b9d43219ed804c48bbf'
But the release tarball does not contain those paths. Here is what my source tree looks like from expanding the release tarball.
$ ls
CMakeLists.txt Jenkinsfile cmake docs scripts tools
CONTRIBUTING.md LICENSE conan.lock install_build_dependencies.sh src vcpkg.json
CONTRIBUTING_DOCS.md README.md conanfile.txt licensing tests
CONTRIBUTING_PR.md SECURITY.md cspell.json samples thirdparty
$ ls thirdparty/
cnpy flatbuffers gtest ittapi ocl open_model_zoo pugixml telemetry zlib
dependencies.cmake gflags itt_collector json onnx protobuf snappy xbyak
Another difference is that you rely on the install_build_dependencies.sh script to install the dependencies from the build distribution. We have to do this manually since we're cross compiling under a custom distribution that doesn't have those dependencies. So adding them to their respective directories under <openvino>/thirdparty is necessary. To be clear, I manually build and install oneTBB and xbyak to the cross build staging tree, then copy in the source for the following to their respective directories under <openvino>/thirdparty.
- pugixml
- gflags
- protocolbuffers
- flatbuffers
- snappy
- onnx
- nlohmann
- zlib
I'm also not currently setting the OpenCL vendors path. Does that need to be relative to the runtime (re: target) root filesystem or to the build (re: staging tree) filesystem? In other words, is OPENCL_VENDOR_PATH used just by the build or is it used by the runtime (or is it used by both and has to be the same in both places)?
I also do not specifically call the build of the samples directory but hello_query_device gets built anyway and the generated binary is stored in <openvino>/bin/Release.
I'm going to try the build by manually generating the tarball from the cloned git repo AFTER I've updated the submodules so I have an identical source tree to yours.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Correction: I showed the thirdparty directory as missing those submodules. The submodules are under src/plugins. I just verified that my release tarball does not contain the source for the src/plugins/*/thirdparty/* submodules but the git repo does after the submodule update. I was wrong about the location, but the problem is still there - I need a tarball with the submodule source to be equivalent to your source tree.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I remade my tarball for the build to include the submodules and rebuilt. I also specifically built the samples. But there is no change.
$ ./hello_query_device
[ INFO ] Build ................................. 2024.1.0-8999-87b66987306-feature/QSYSDEV-35209
[ INFO ]
[ INFO ] Available devices:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Is there a way to verify what plugins are enabled in the runtime tools? It seems like the CPU/GPU/NPU plugins might not be enabled in the core even though it seems like there were compiled.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Mjhammel,
Thank you for the details provided.
We are checking with the relevant team for further investigation regarding your issue. We will get back to you soon, Thank you,
Regards,
Megat
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @Megat_Intel ,
I am facing the same issue and oddly, the available devices is visible using the openvino python distribution. I am on the latest python distribution and for C++ am using the openvino 2024.2 archive, testing using the hello_query_device C++ sample.
My system information:
CPU: Core i7-1335U
Python:
C++:
Please let me know if you want to see any code or other information.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
From our end, we have tried multiple ways to reproduce the issue but we are unable to encounter it.
Hence we assume, these are the possible reasons for this issue:
- There could be a configuration error in the file or the driver for C++ is not fully configured during the build process.
- There could be some version of the driver/application that does not tally with OpenVINO, hence the detection is not present.
We suggest for you to use the supported OSes to install OpenVINO because those OSes are officially tested and verified.
Other OSes (other than supported OSes) might not be fully supported.
Cordially,
Iffa
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Intel will no longer monitor this thread since we have provided a solution. If you need any additional information from Intel, please submit a new question.
Cordially,
Iffa

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page