pi_die: Check if plugin is present. Failed to load plugin: libpi_opencl.so

[jeffhammond]

I see this issue with Ubuntu 19.04 with OpenCL as instructed in https://github.com/intel/compute-runtime/blob/master/documentation/Neo_in_distributions.md#ubuntu-1904-1910.

Skipping host device since it is too slow for large problems
pi_die: Check if plugin is present. Failed to load plugin: libpi_opencl.so
terminate called without an active exception

How do I debug this?

[AlexeySachkov]

@jeffhammond, this should be fixed with #810, could you please check if this patch is included into your SYCL build?

[jeffhammond]

I was using a build from 12 hours ago, so no, I didn't have this patch. I'll try again the next time I can rebuild.

[jeffhammond]

I updated to f9cbf2a and still see the problem.

[AlexeySachkov]

Ok, I've just encountered this by myself, but it was an easy thing to resolve, just ensure that libpi_opencl.so which should be under build/lib is accessible via LD_LIBRARY_PATH.

#708 has introduced Plugin Interface as it is described in the docs. Now SYCL runtime contains not only libsycl.so, but also some additional plugins. In particular, libpi_opencl.so is an interface to OpenCL runtimes.

@jeffhammond, could you please check that path to libpi_opencl.so is in your LD_LIBRARY_PATH? As I can see here, plugin libraries are loaded by simple dlopen right now

[jeffhammond]

I am not going to reference files in the build directory, because that is transient. The library is in the install directory and I set -Wl,-rpath to that location already. It would be nice if the compiler could look in rpath. I'd also like to be able to use a custom environment variable so that I don't have to mess with LD_LIBRARY_PATH.

[cbenthin]

I've run into the same missing libpi_opencl.so issue, but the latest run-time or compiler do not include this .so file. Where did you get it from?

[jeffhammond]

@cbenthin
I find it in the build and install directories:

$ locate libpi_opencl.so
/home/jrhammon/ISYCL/build/lib/libpi_opencl.so
/opt/isycl/lib/libpi_opencl.so

[jeffhammond]

@AlexeySachkov After updating LD_LIBRARY_PATH, it now fails here:

Parallel Research Kernels version 2.16
C++11/SYCL STREAM triad: A = B + scalar * C
Number of iterations = 10
Vector length        = 1000000
Offset               = 0
Skipping host device since it is too slow for large problems
Abort was called at 22 line in file:
../neo/runtime/gmm_helper/gmm_interface.cpp
Aborted (core dumped)

[cbenthin]

I guess you compile from source while I pick the binary releases and libpi_opencl.so is not included in the package.

[jeffhammond]

@cbenthin Yes, I am building the latest git from source every time.

[jeffhammond]

I guess the problem is in OpenCL, but I've reinstalled NEO per https://github.com/intel/compute-runtime/blob/master/documentation/Neo_in_distributions.md#ubuntu-1904-1910 multiple times now to no avail.

What is really odd is that it crashes on the host selector. I don't really understand why our SYCL compiler is initializing OpenCL in order to use the explicitly non-OpenCL back-end.

sycl::queue q(sycl::host_selector{});

Abort was called at 22 line in file:
../neo/runtime/gmm_helper/gmm_interface.cpp

Thread 1 "nstream-sycl" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007ffff77e3535 in __GI_abort () at abort.c:79
#2  0x00007ffff70c7529 in NEO::abortExecution() ()
   from /opt/intel/yolo/compiler/1.0.0/lib/oclgpu/intel-opencl/libigdrcl.so
#3  0x00007ffff70c7601 in NEO::abortUnrecoverable(int, char const*) ()
   from /opt/intel/yolo/compiler/1.0.0/lib/oclgpu/intel-opencl/libigdrcl.so
#4  0x00007ffff71243cb in NEO::GmmHelper::loadLib() ()
   from /opt/intel/yolo/compiler/1.0.0/lib/oclgpu/intel-opencl/libigdrcl.so
#5  0x00007ffff7123d26 in NEO::GmmHelper::initContext(PLATFORM_STR const*, NEO::FeatureTable const*, NEO::WorkaroundTable const*, GT_SYSTEM_INFO const*) ()
   from /opt/intel/yolo/compiler/1.0.0/lib/oclgpu/intel-opencl/libigdrcl.so
#6  0x00007ffff7124031 in NEO::GmmHelper::GmmHelper(NEO::HardwareInfo const*) ()
   from /opt/intel/yolo/compiler/1.0.0/lib/oclgpu/intel-opencl/libigdrcl.so
#7  0x00007ffff71100b3 in NEO::ExecutionEnvironment::initGmm() ()
   from /opt/intel/yolo/compiler/1.0.0/lib/oclgpu/intel-opencl/libigdrcl.so
#8  0x00007ffff70dff8d in NEO::Device::createDeviceImpl() ()
   from /opt/intel/yolo/compiler/1.0.0/lib/oclgpu/intel-opencl/libigdrcl.so
#9  0x00007ffff70ca59a in NEO::Platform::initialize() ()
   from /opt/intel/yolo/compiler/1.0.0/lib/oclgpu/intel-opencl/libigdrcl.so
#10 0x00007ffff70a8e2b in clGetPlatformIDs ()
   from /opt/intel/yolo/compiler/1.0.0/lib/oclgpu/intel-opencl/libigdrcl.so
#11 0x00007ffff75b7b98 in ?? () from /usr/lib/x86_64-linux-gnu/libOpenCL.so.1
#12 0x00007ffff75b80d3 in clGetPlatformIDs () from /usr/lib/x86_64-linux-gnu/libOpenCL.so.1
#13 0x00007ffff7d09729 in OclpiPlatformsGet () from /opt/isycl/lib/libpi_opencl.so
#14 0x00007ffff7f44d33 in cl::sycl::detail::platform_impl_pi::get_platforms() ()
   from /opt/isycl/lib/libsycl.so
#15 0x00007ffff7f76390 in cl::sycl::platform::get_platforms() () from /opt/isycl/lib/libsycl.so
#16 0x00007ffff7f6dcad in cl::sycl::device::get_devices(cl::sycl::info::device_type) ()
   from /opt/isycl/lib/libsycl.so
#17 0x00007ffff7f73e68 in cl::sycl::device_selector::select_device() const ()
   from /opt/isycl/lib/libsycl.so
#18 0x000000000040678c in cl::sycl::queue::queue (this=0x7fffffffbbe8, deviceSelector=..., 
    propList=...) at /opt/isycl/lib/clang/10.0.0/include/CL/sycl/queue.hpp:37
#19 0x0000000000406171 in main (argc=3, argv=0x7fffffffbd58) at nstream-sycl.cc:224

[jeffhammond]

This appears to be a NEO problem (intel/compute-runtime#230). However, I would like SYCL to (1) not touch OpenCL when using the host device and (2) detect or otherwise mitigate whatever OpenCL problem is causing this.

[smaslov-intel]

I think theses are both valid requests for improvement, could file them as Jira issues, please?