- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, again
I have already installed SDK 2017 r2 and system_studio. But when I use"clinfo" at the end of log.
And I also "sudo apt install ocl-icd-opencl-dev" still showed as below.
I thinks it's really a stupid question but it stuck me a lot.
Thanks
NULL platform behavior clGetPlatformInfo(NULL, CL_PLATFORM_NAME, ...) No platform clGetDeviceIDs(NULL, CL_DEVICE_TYPE_ALL, ...) No platform clCreateContext(NULL, ...) [default] No platform clCreateContext(NULL, ...) [other] Success [INTEL] clCreateContextFromType(NULL, CL_DEVICE_TYPE_CPU) No platform clCreateContextFromType(NULL, CL_DEVICE_TYPE_GPU) No platform clCreateContextFromType(NULL, CL_DEVICE_TYPE_ACCELERATOR) No platform clCreateContextFromType(NULL, CL_DEVICE_TYPE_CUSTOM) No platform clCreateContextFromType(NULL, CL_DEVICE_TYPE_ALL) No platform NOTE: your OpenCL library only supports OpenCL 1.2, but some installed platforms support OpenCL 2.1. Programs using 2.1 features may crash or behave unexepectedly
But
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi again,
I find when I finished install Intel® CPU Runtime for OpenCL™ Applications 18.1 for Linux* OS (64bit only) I checked the folder "/etc/alternatives" found the symbolic is not correct.
shan@shan-ZHAOYANG-E51-80:/etc/alternatives$ ll |grep opencl
lrwxrwxrwx 1 root root 64 Nov 21 17:24 opencl-intel-runtime -> /opt/intel/CPU_runlib//opencl_compilers_and_libraries_18.1.0.013/
lrwxrwxrwx 1 root root 86 Nov 21 17:24 opencl-intel-runtime-icd -> /opt/intel/CPU_runlib//opencl_compilers_and_libraries_18.1.0.013/linux/etc/intel64.icd
lrwxrwxrwx 1 root root 108 Nov 21 17:24 opencl-libOpenCL.so -> /opt/intel/CPU_runlib//opencl_compilers_and_libraries_18.1.0.013/linux/compiler/lib/intel64_lin/libOpenCL.so*
lrwxrwxrwx 1 root root 110 Nov 21 17:24 opencl-libOpenCL.so.1 -> /opt/intel/CPU_runlib//opencl_compilers_and_libraries_18.1.0.013/linux/compiler/lib/intel64_lin/libOpenCL.so.1*
lrwxrwxrwx 1 root root 112 Nov 21 17:24 opencl-libOpenCL.so.2.0 -> /opt/intel/CPU_runlib//opencl_compilers_and_libraries_18.1.0.013/linux/compiler/lib/intel64_lin/libOpenCL.so.2.0*
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi ShanL,
Thanks for the questions and your continued interest. These questions are very useful.
OpenCL implementations often come with the ICD interrogator libraries. Their installers may deploy them and create symlinks and system path expectations. Recent Intel implementations for Linux OS come with the ICD interrogator library which for CPU and Intel Graphics Technology should be OpenCL 2.1 api capable. The device kernels should be OpenCL-C 2.0 capable for those implementations. The included ICD interrogator library is the reference Khronos library... It is not the ocl-icd project build which may have some extended behaviors.
I can't look at that clinfo sources at the moment... but is it possible a non-Intel implementation is only 1.2 capable while the ICD loader from Intel's deployment is 2.1 capable? The good thing about the ICD loader library being 2.1 is that developers can still write a program using 1.2 (continuing to 2.1) features, or many deprecated 1.2 function calls... The healthiest development workflow involves interrogating the implementation to understand it's version then use the corresponding function calls for that API revision.
One such example of a deprecated difference that users often run into is command queue creation... the standard 1.2 call was deprecated as of 2.0... the 2.0+ call required a data structure for command queue properties.
https://www.khronos.org/registry/OpenCL/sdk/1.2/docs/man/xhtml/clCreateCommandQueue.html
See this macro included underneath cl.h which allows for toggling between the two for more context: CL_USE_DEPRECATED_OPENCL_1_2_APIS
Also relevant is kernel side OpenCL-C standard source which may necessitate -cl-std=CL2.0 for the kernel build options with newer implementations and source features.
It's also possible that 1.2 capable libOpenCL.so was picked up by clinfo which would may have difficulty with 2.0+ implementations. Determining ICD loader library (libOpenCL.so) revision on the deployment system is best practice for portability and stability. Systems with multiple vendors or SDKs may which to set LD_LIBRARY_PATH to find a dir with an appropriate implementation to evaluate behavioral discrepancies.
It just so happens that the Windows MSVS 2017 template exmaples for OpenCL included in Intel® System Studio 2019 have some good examples for how to deal with the 2.0 API revision difference. If a system is available to try those sources I recommend looking at them in the CPU and GPU templates.
Thanks,
-MichaelC
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Got a question about my Folding@Home box. It has 2 x NVidia Cards (details below). I am getting funny output at the end of "clinfo" on Fedora 31.
Thanks! JW
I run clinfo on the console, and finishes with a:
NULL platform behavior
clGetPlatformInfo(NULL, CL_PLATFORM_NAME, ...) No platform
cl_get_gt_device(): error, unknown device: 0
clGetDeviceIDs(NULL, CL_DEVICE_TYPE_ALL, ...) �����U
clCreateContext(NULL, ...) [default] No devices found in platform
clCreateContext(NULL, ...) [other] Success [POCL]
cl_get_gt_device(): error, unknown device: 0
clCreateContextFromType(NULL, CL_DEVICE_TYPE_DEFAULT) No devices found in platform
clCreateContextFromType(NULL, CL_DEVICE_TYPE_CPU) No devices found in platform
cl_get_gt_device(): error, unknown device: 0
clCreateContextFromType(NULL, CL_DEVICE_TYPE_GPU) No devices found in platform
clCreateContextFromType(NULL, CL_DEVICE_TYPE_ACCELERATOR) No devices found in platform
clCreateContextFromType(NULL, CL_DEVICE_TYPE_CUSTOM) No devices found in platform
cl_get_gt_device(): error, unknown device: 0
clCreateContextFromType(NULL, CL_DEVICE_TYPE_ALL) No devices found in platform
But it behaves differently when I shell in from remote:
(in the case below Coffee is my system with GTX770 and RTX2060 - my Folding@home rig )
but.. if I run clinfo over an ssh session (where glxgears works properly) yields:
[root@coffee tmp]# clinfo
X Error of failed request: BadRequest (invalid request code or no such operation)
Major opcode of failed request: 154 (DRI2)
Minor opcode of failed request: 1 (DRI2Connect)
Serial number of failed request: 11
Current serial number in output stream: 11
Devices:
[root@coffee tmp]# ls -l /dev/dri drwxrwxrwx 2 root root 120 Mar 31 12:57 by-path crw-rw-rw-+ 1 root video 226, 0 Mar 31 12:57 card0 crw-rw-rw-+ 1 root video 226, 1 Mar 31 12:57 card1 crw-rw-rw- 1 root render 226, 128 Mar 31 12:57 renderD128 crw-rw-rw- 1 root render 226, 129 Mar 31 12:57 renderD129
2 different cl.h files:
[root@coffee tmp]# locate cl.h | grep /cl.h /usr/include/CL/cl.h /usr/local/cuda-10.2/targets/x86_64-linux/include/CL/cl.h
Where do clinfo look for .so?
[root@coffee tmp]# locate clinfo | grep bin /usr/bin/clinfo
[root@coffee tmp]# ldd /usr/bin/clinfo linux-vdso.so.1 (0x00007ffce72f2000) libOpenCL.so.1 => /lib64/libOpenCL.so.1 (0x00007f07aaa01000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f07aa9fa000) libc.so.6 => /lib64/libc.so.6 (0x00007f07aa831000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f07aa80f000) /lib64/ld-linux-x86-64.so.2 (0x00007f07aac54000)
What is libOpenCL sourced from?
[root@coffee tmp]# rpm -qf /lib64/libOpenCL.so.1 ocl-icd-2.2.12-6.fc31.x86_64
what other OCL rpms are involved?
[root@coffee tmp]# rpm -qa | grep ocl ocl-icd-devel-2.2.12-6.fc31.x86_64 ocl-icd-2.2.12-6.fc31.x86_64 ocl-icd-2.2.12-6.fc31.i686 [root@coffee tmp]#
NVidia RPMS
[root@coffee ~]# rpm -qa | grep nvidia | sort akmod-nvidia-440.33.01-1.fc29.x86_64 nvidia-driver-440.33.01-1.fc29.x86_64 nvidia-driver-cuda-440.33.01-1.fc29.x86_64 nvidia-driver-cuda-libs-440.33.01-1.fc29.x86_64 nvidia-driver-devel-440.33.01-1.fc29.x86_64 nvidia-driver-libs-440.33.01-1.fc29.x86_64 nvidia-driver-NvFBCOpenGL-440.33.01-1.fc29.x86_64 nvidia-driver-NVML-440.33.01-1.fc29.x86_64 nvidia-kmod-common-440.33.01-1.fc29.x86_64 nvidia-libXNVCtrl-440.33.01-1.fc29.x86_64 nvidia-libXNVCtrl-devel-440.33.01-1.fc29.x86_64 nvidia-modprobe-440.33.01-1.fc29.x86_64 nvidia-persistenced-440.33.01-1.fc29.x86_64 nvidia-settings-440.33.01-1.fc29.x86_64 nvidia-xconfig-440.33.01-1.fc29.x86_64
Cuda libs from NVidia package:
NVIDIA-Linux-x86_64-440.64.run
Folding at home seems ok with LibCuda:
7:29:21: CPU: Intel(R) Core(TM) i3-8350K CPU @ 4.00GHz 17:29:21: CPU ID: GenuineIntel Family 6 Model 158 Stepping 11 17:29:21: CPUs: 4 17:29:21: Memory: 15.56GiB 17:29:21: Free Memory: 14.07GiB 17:29:21: Threads: POSIX_THREADS 17:29:21: OS Version: 5.5 17:29:21: Has Battery: false 17:29:21: On Battery: false 17:29:21: UTC Offset: -4 17:29:21: PID: 9515 17:29:21: CWD: /var/lib/fahclient 17:29:21: OS: Linux 5.5.8-200.fc31.x86_64 x86_64 17:29:21: OS Arch: AMD64 17:29:21: GPUs: 2 17:29:21: GPU 0: Bus:1 Slot:0 Func:0 NVIDIA:7 TU106 [Geforce RTX 2060] 17:29:21: GPU 1: Bus:2 Slot:0 Func:0 NVIDIA:3 GK104 [GeForce GTX 770] 3213 17:29:21:CUDA Device 0: Platform:0 Device:0 Bus:1 Slot:0 Compute:7.5 Driver:10.2 17:29:21:CUDA Device 1: Platform:0 Device:1 Bus:2 Slot:0 Compute:3.0 Driver:10.2 17:29:21: OpenCL: Not detected: clGetDeviceIDs() returned -1
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page