XRT is invoked when run a compiled C++ program

[haipnh]

Hi,

I have an Alveo U50 card and I use Ubuntu 18.04. Although I don't use the card in my code, the XRT will be invoke when I run the C++ program (fully processed by CPU).

I'm not sure this phenomenon is normal or not. But it may affect to the performance measurement of some lines of C++ code.

The pseudo code is:

int main() {
  std::cout << "Start!\n";
  // do some processes
  std::cout << "End!\n";
}

My build command:

g++ ./main.cpp -o main -lopencv_core -lopencv_imgcodecs -lopencv_highgui -lopencv_imgproc
./main

Output:

Start!
XRT build version: 2.13.466
Build hash: f5505e402c2ca1ffe45eb6d3a9399b23a0dc8776
Build date: 2022-04-14 17:45:07
Git branch: 2022.1
PID: 32458
UID: 1004
[Wed Mar 22 16:24:39 2023 GMT]
HOST: End!

I checked my bashrc, it does not source xrt's setup.sh by default.

[haipnh]

I said "it may affect to the performance measurement of some lines of C++ code." because I performed the same operation 2 times, with the XRT invoked, there are some delays.

Start!
XRT build version: 2.13.466
Build hash: f5505e402c2ca1ffe45eb6d3a9399b23a0dc8776
Build date: 2022-04-14 17:45:07
Git branch: 2022.1
PID: 14820
UID: 1004
[Thu Mar 23 06:08:55 2023 GMT]
HOST: Dark channel OCV main(): 7.60444 ms
Dark channel OCV dc_ocv(): 1.68586 ms
End!

If I use Vitis HLS to build the code, this phenomenon will be gone. The difference of execute time between function call and in main() is under 1ms.

[wilderfield]

XRT will not be invoked unless your C++ program invokes it. I don't think it's possible for XRT to slow down unrelated C++ code. XRT is not a server or daemon.

[keryell]

I guess the problem is that XRT exposes an OpenCL device with /etc/OpenCL/vendors/xilinx.icd, so any OpenCL usage might kick in XRT. If you want to avoid this you can temporarily remove or rename this file to some other extension.

[HPC-Ken]

This also occurs when using MPI without any opencv/xrt linkage or includes.

[keryell]

Either you are using a quantum computer or someone is lying to you. :-) Can you ldd your binary to see whether you are not pulling some OpenCL library by side effect of other libraries? Are you using some script or job scheduler which for example could run some OpenCL information command before your program? How are you compiling/executing with MPI? I hope you are not sourcing any Vitis-related configuration file. At the end strace -f is your friend.

[HPC-Ken]

ldd output linux-vdso.so.1 (0x00007ffc1b9f2000) libmpi_cxx.so.40 => /usr/local/lib/libmpi_cxx.so.40 (0x00007f99f82d9000) libmpi.so.40 => /usr/local/lib/libmpi.so.40 (0x00007f99f8186000) libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f99f7f8b000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f99f7f70000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f99f7d7e000) libopen-pal.so.40 => /usr/local/lib/libopen-pal.so.40 (0x00007f99f7cb1000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f99f7c8c000) libopen-rte.so.40 => /usr/local/lib/libopen-rte.so.40 (0x00007f99f7bcf000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f99f7a80000) libhwloc.so.15 => /lib/x86_64-linux-gnu/libhwloc.so.15 (0x00007f99f7a2f000) /lib64/ld-linux-x86-64.so.2 (0x00007f99f8313000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f99f7a29000) libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f99f7a24000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f99f7a06000) libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x00007f99f79d9000) libltdl.so.7 => /lib/x86_64-linux-gnu/libltdl.so.7 (0x00007f99f79ce000)

Compiling with mpicxx main.cpp, run with mpirun -np 1 ./a.out

I can tell you that xrt is sourced by my bashrc but I'm not using it in my application, which is simply MPI_Init and MPI_Finalize.

[keryell]

Otherwise in the case of OpenCV it is possible to disable OpenCL at runtime https://github.com/opencv/opencv/wiki/OpenCL-optimizations or even at compile time if you compile it yourself

[keryell]

hwloc can introspect OpenCL: https://www.open-mpi.org/projects/hwloc/doc/v2.1.0/a00179.php You can look recursively at your libraries (I do not know whether there is an automated way): ldd /lib/x86_64-linux-gnu/libhwloc.so.15