OpenCL* for CPU
Ask questions and share information on Intel® SDK for OpenCL™ Applications and OpenCL™ implementations for Intel® CPU.
Announcements
This forum covers OpenCL* for CPU only. OpenCL* for GPU questions can be asked in the GPU Compute Software forum. Intel® FPGA SDK for OpenCL™ questions can be ask in the FPGA Intel® High Level Design forum.
1719 Discussions

NOTE:your OpenCL library only supports OpenCL 1.2, but some installed platforms support OpenCL 2.1.

Lu__Shan
Beginner
3,114 Views

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

0 Kudos
3 Replies
Lu__Shan
Beginner
3,114 Views

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*
 

0 Kudos
Michael_C_Intel1
Moderator
3,114 Views

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

https://www.khronos.org/registry/OpenCL/sdk/2.1/docs/man/xhtml/clCreateCommandQueueWithProperties.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

 

 

0 Kudos
JWest32
Beginner
3,114 Views

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

 

0 Kudos
Reply