Michal Babej

@diegoxfx hello can you retest with `release_1_8` branch, ideally with LLVM >= 12 ? i've noticed you used `pocl 1.5, Release, LLVM 10.0.0` both versions are fairly old, it's quite...

Try removing the lines https://github.com/pocl/pocl/blob/be7fab566ce54bc152bab1789b60b35808e666b9/cmake/LLVM.cmake#L147 to https://github.com/pocl/pocl/blob/be7fab566ce54bc152bab1789b60b35808e666b9/cmake/LLVM.cmake#L149 Historically LLVM's CPU detection on ARM was quite bad which is why we use this trick. Perhaps it's now good enough in recent...

I've changed the logic in commit 58c5de69c184a661cb9. Now if it detects ocl-icd with 3.0 support, it'll automatically use PoCL's internal 3.0 headers (older ocl-icd or other loaders will still use...

Pocl by default does CPU detection during CMake time, but with some CMake options it can be configured to create a "dynamic" build where it does the CPU detection at...

No, LLVM-less build is entirely different thing. The "dynamic" (in the sense of runtime CPU detection) build requires LLVM and is enabled by running CMake with `-DKERNELLIB_HOST_CPU_VARIANTS=distro` option. Does `llc...

@pjaaskel AFAICT the problem is not the ICD loading `libpocl.so`, the problem is `libpocl.so` not finding `libpocl-devices-basic.so` (and/or other drivers) to dlopen. @mssx86 rpath isn't going to help, because libpocl...

> apparently libllvmopencl.so not being linked against libLLVM-* is normal behavior. Yes. libllvmopencl.so is not supposed to be linked against anything (except libc). > i have no idea how the...

You can get more useful log if you run at least one test with `POCL_DEBUG=all` like this: ``` POCL_DEBUG=all ctest -V -R kernel/test_shuffle_char ```

It would seem LLVM doesn't recognize your CPU for whatever reason. Can you provide a full log of CMake ? (in a clean build directory)

I see. In that case, i suggest you file a bug with the distribution, and link this bug into their bug tracker.