Sandy Bridge, INDE OK while IOC64 and runtime fails (W8.1 -I7 2760)

[Gei_A_]

Hi,

I have a piece of code that runs fine on Ivy bridge and later CPU's. On Sandy Bridge (2760) it will not vectorize and hence it will not perform.

Now, the same code will compile and run if we use your competitors runtime.

Our problem is that the INDE compiler will vectorize it but when we use the IOC64 directly it simply says compile failure. Is it safe to assume that the toolkit is using the same compiler?

Further, the -Scholar mode does not work?

Any ideas?

Geir

[Robert_I_Intel]

Hi Geir,

Could you please provide a sample kernel and a log of the failure?

Also, please let me know the version of the OpenCL driver are you using?

[Uri_L_Intel]

Hello Geir,

Please note that OpenCL support on Intel HD Graphics (GPU) is not supported on Sandy Bridge platform (you can see more details on supported platforms in our product's release notes: https://software.intel.com/file/458086/download)

If you're developing for the CPU device you can install the latest version of OpenCL Runtime 15.1 for Intel(R) Core(TM) processors from here: https://software.intel.com/en-us/articles/opencl-drivers#win64

(Keep in mind that INDE does not contain the OpenCL driver, so you'll need to install it seperatly)

As for the -Scholar option, this feature is no longer supported on latest versions of Code Builder.

Thanks,

Uri

[Gei_A_]

Gents,

thank you for your response. First of all, on the platform in question I have the following openCl devices available (Yes it's a laptop running W8.1 64):

- nVidia Cuda (Quadro 1000)

- Intel OpenCl (15.1) (CPU)

- AMPP (CPU)

- Intel OpenCl experimental 2.0 (CPU).

All drivers and SDKs are of the latest stable release. It will vectorize and run on all of the above apart from the Intel OpenCl 1.5 implementation.

Now, our immediate goal is to get this running on a number of workstations using Intel Xeon Processor E5-2620 v2 6C.   But we only have a 2760 to test on as of today.

I have to admit that I have only had a couple of days to get up to speed on OpenCl..

Anyway, how can I sent you the kernel file as a private file?

Please find below the logs:

This is the command line version:

ioc64 -cmd=build -input=kernel.cl
Setting target instruction set architecture to: Default (Advanced Vector Extension (AVX))
OpenCL Intel CPU device was found!
Device name: Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz
Device version: OpenCL 1.2 (Build 57)
Device vendor: Intel(R) Corporation
Device profile: FULL_PROFILE
Compilation started
Compilation failed

Build failed!

This  is the output from the code builder (32 and 64):

Setting target instruction set architecture to: Default (Advanced Vector Extension (AVX))

OpenCL Intel CPU device was found!

Device name: Intel(R) Core(TM) i7-2760QM CPU @ 2.40GHz

Device version: OpenCL 1.2 (Build 57)

Device vendor: Intel(R) Corporation

Device profile: FULL_PROFILE

Compilation started

Compilation done

Linking started

Linking done

Device build started

Device build done

Kernel <Tes1> was successfully vectorized (4)

Kernel <Test2> was successfully vectorized (4)

Done.

Build succeeded!

Maybe we need to provide the CMD line tool a couple of options?

Geir

[Gei_A_]

Update:

This is getting ridiculous..
The cmd line version fails with the following code:

Test 1:
/* Please Write the OpenCL Kernel(s) code here*/

//end of code (Yes it only contains a comment)

Test 2:

#pragma OPENCL EXTENSION cl_khr_byte_addressable_store : enable
__constant char hw[] = "Hello World\n";
__kernel void hello(__global char * out) {
   size_t tid = get_global_id(0);
   out[tid] = hw[tid];
}

While codebuilder ok's them both....

Are there any build logs available anywhere? Could not find them in appdata.
Further, the registry seems ok.
 

Geir

[Gei_A_]

We have now confirmed that this goes for Win7 too.

When we install OpenCl ver 15.1 runtime the intel compiler will not compile if called from "random locations".

For older versions it will.

So this is not a Win8 issue, but a SDK issue.

But I guess problem solved for us.

Geir