I have just compiled ViennaCL 1.4.2 on the XEON PHI, but all examples (with OpenCL) run on the CPU host. How do I set the system up to run OpenCL on the MIC instead? Thanks. Gordon.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, the MIC is selected via set_context_device_type();
At first I was fairly surprised that Intel prefers the CPU over the MIC in their current OpenCL SDK. However, our current experiences with further tuning for MIC showed that the OpenCL implementation for the MIC is still in its infancy: PCI-Express latency is huge (i.e. significantly larger than for AMD and NVIDIA GPUs) and also the generated code does not seem to be optimal. This may explain why the Intel SDK by default suggests to use the CPU for OpenCL right now.
(This may change with future updates of the Intel OpenCL SDK)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have heard complaints about OpenCL. Would anything prevent me running ViennaCL on MIC directly just pretending it's a normal x86 CPU with 61 cores/244 threads?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hey Bill, ViennaCL runs on the MIC with a few extra steps:
1) Tell ViennaCL to look for MIC (TYPE_ACCELERATOR):
viennacl::ocl::set_context_device_type (0, CL_DEVICE_TYPE_GPU |
CL_DEVICE_TYPE_ACCELERATOR);
2) Make sure you have the Intel OpenCL (Beta) installed.
3) Disable the use of Images in OpenCL kernels (not supported by Intel
at the moment). I forget if ViennaCL has any of these enabled by
default.
As far as the 61 cores go, 1 of them is always dedicated to the OS, so
assume 60. However, if you have a production MIC card you only have 60
total cores, so assume 59 available.
Don't expect the greatest results with ViennaCL on the MIC. The OpenCL
driver is still beta and slow. Plus the ViennaCL kernels were designed
with a GPU in mind. Functional portability does not guarantee
performance portability. I'm seeing the MIC run the same kernels at
about 1/10th the speed of a K20.
I have heard complaints about OpenCL. Would anything prevent me running
ViennaCL on MIC directly just pretending it's a normal x86 CPU with 61
cores/244 threads?
I have just compiled ViennaCL 1.4.2 on the XEON PHI, but all examples (with OpenCL) run on the CPU host. How do I set the system up to run OpenCL on the MIC instead? Thanks. Gordon.
One way to do this:
viennacl::ocl::set_context_device_type(0, viennacl::ocl::accelerator_tag());
Yes, the MIC is selected via set_context_device_type();
At first I was fairly surprised that Intel prefers the CPU over the MIC in their current OpenCL SDK. However, our current experiences with further tuning for MIC showed that the OpenCL implementation for the MIC is still in its infancy: PCI-Express latency is huge (i.e. significantly larger than for AMD and NVIDIA GPUs) and also the generated code does not seem to be optimal. This may explain why the Intel SDK by default suggests to use the CPU for OpenCL right now.
(This may change with future updates of the Intel OpenCL SDK)
I have heard complaints about OpenCL. Would anything prevent me running ViennaCL on MIC directly just pretending it's a normal x86 CPU with 61 cores/244 threads?
Hey Bill, ViennaCL runs on the MIC with a few extra steps:
1) Tell ViennaCL to look for MIC (TYPE_ACCELERATOR):
viennacl::ocl::set_context_device_type (0, CL_DEVICE_TYPE_GPU |
CL_DEVICE_TYPE_ACCELERATOR);
2) Make sure you have the Intel OpenCL (Beta) installed.
3) Disable the use of Images in OpenCL kernels (not supported by Intel
at the moment). I forget if ViennaCL has any of these enabled by
default.
As far as the 61 cores go, 1 of them is always dedicated to the OS, so
assume 60. However, if you have a production MIC card you only have 60
total cores, so assume 59 available.
Don't expect the greatest results with ViennaCL on the MIC. The OpenCL
driver is still beta and slow. Plus the ViennaCL kernels were designed
with a GPU in mind. Functional portability does not guarantee
performance portability. I'm seeing the MIC run the same kernels at
about 1/10th the speed of a K20.
Cheers,
-E
On Wed, Aug 7, 2013 at 7:01 PM, Bill Broadley billbroadley@users.sf.net wrote:
--
-Evan Bollig
bollig@gmail.com
bollig@scs.fsu.edu