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.
1663 Discussions

Experimental OpenCL 2.1 CPU only platform crashes when used *after* another Intel CPU only platform

Achille_P_
Beginner
289 Views

Hi,

I've two Intel CPU only platforms installed on my (Windows 10 64 bit) development machine:

1) Intel OpenCL 1.2 (build 25), version 6.4.0.25 (the one available as standalone installer version 16.1.1)
2) Experimental OpenCL 2.1 CPU Only Platform (build 10), version 7.0.0.2519 (the one available through the Intel OpenCL SDK)

When within one same process I iterate through the available platforms/devices to check their specs and I create a context to run a simple kernel (just to make sure the platform/device really works), the Experimental OpenCL 2.1 platform fails during the clBuildProgram() method, complaining about non-sense things such as "use of undeclared identified 'size_t'; did you mean 'sizeof'?", "implicit declaration of get_global_id() is invalid in OpenCL" and so on. 

It looks like the compiler of the Experimental OpenCL 2.1 runtime goes nuts if I previously initialized a context and used the Intel OpenCL 1.2 runtime. Maybe some per-process state that is not properly cleaned or managed across the two runtime versions. 

If I comment out the portion of code initializing the first context (the one on the Intel OpenCL 1.2 runtime), the Experimental OpenCL 2.1 runtime works as expected. 

This issue can be easily replicated by installing the two aforementioned runtime versions on one same machine and by running "clinfo". 

0 Kudos
2 Replies
Michael_C_Intel1
Moderator
289 Views

Hello Achille,

Thanks for documenting your experience.

For cases like these, it's recommended to stick to one instance of the runtime if possible, and removing previous installations before switching. There's a bit of nuance between runtime and driver that changes what kind of resolution could work in a case like this. So far, it's difficult to determine if the case requires an issue sighting, is in appropriate use case, or has an appropriate work around.

Can you share:

  • How are you linking? In general, it's recommended to link against the lib provided in the SDK when possible.
  • What hardware you are attempting to run on? Can you share the CPU and graphics coprocessor for completeness?
  • Either your source code as is or slimmed down source as a minimally sufficient reproducer?

Thanks

 

 

 

Achille_P_
Beginner
289 Views

MICHAEL C. (Intel) wrote:

  • How are you linking? In general, it's recommended to link against the lib provided in the SDK when possible.
  • What hardware you are attempting to run on? Can you share the CPU and graphics coprocessor for completeness?
  • Either your source code as is or slimmed down source as a minimally sufficient reproducer?

Hi Michael,

thank you for your answer. Let me quickly give a response to your questions:

1) We redistribute our version of libOpenCL. We need to do that for a series of reasons, but it works well (this case a part, of course). 

2) My office workstation, which is a 1.5 years old high-end computer with a 6 core Intel 7 processor without integrated graphics (I'm out of office, don't remember the exact version number right now), 64 GB of RAM, Windows 10 64 bit, 2x AMD FirePro 8100W. I installed 3 OpenCL runtimes: Intel CPU-only stand-alone v6.4.something (the ones that you manually download and install), AMD one (including the GPU and CPU-only support), and the Intel Experimental, as part of the Intel OpenCL SDK.

EDIT: Forgot to mention that the same problem happens on a colleague's laptop with quite different CPU and HW specs. 

3) You can easily reproduce the issue using "clinfo". Under Windows I don't recall whether it comes with some Intel OpenCL runtime or with the AMD's one, but you should be able to easily get it. Otherwise, you can run my executable (sarxinfo) by downloading the tools mentioned in section 3.1 here:

http://sarmap.ch/ocl/opencl-install.html

Please keep in mind that this is not really a critical issue, as long as these experimental runtimes and/or multiple Intel CPU-only runtimes do not mess with a standard user installation. Unfortunately (see my other topics) we are getting several support requests from users who somehow ended up in having a corrupted Intel OpenCL CPU-only runtime on their machines. It might be due to several reasons, like both experimental and official runtimes installed, the CPU-only runtime integrated in the Intel GPU driver messing with a previously installed CPU-only driver (yes, it happens), CPU-only runtimes no longer working after a Windows 10 upgrade, and so on. 

I think you should consider enforcing to have only *one* Intel CPU-only runtime installed on a computer at a given time. Even better when this runtime can only be installed on demand, by downloading/running the official installer, instead of silently sneaking it disguised into the Intel GPU driver. This would make things so much clearer and simpler for redistributing OpenCL-based applications!

Thanks!

 

Reply