Linux Support

[sjpennycook]

Though I am glad to see that Intel have released an OpenCL compiler, I am disappointed that it currently only runs on Windows platforms; my research is in HPC, and all of the systems that we use run some flavour of Linux.

Are there any plans to support Linux in the near future?

[ARNON_P_Intel]

Thanks for sharing your needs and thoughts with us.

Intel is planning to support OpenCL in our tools and platforms. We are evaluating when and where OpenCL support will intercept our products, including Linux support. However, no announcement has been made.

[Jure_Repinc]

Just adding a comment to show that I'm also only interested in OpenCL support on Linux.

[peastman]

Let me add another vote for this. In the world of HPC, Windows is a mostly irrelevant platform. Clusters are overwhelmingly Linux based, so that's by far the most important platform for us. Mac would be a distant #2, with Windows as an even more distant #3.

Peter

[jogshy]

Bump for linux and Mac here too

[Administrador_Calcul]

The same here. Using currently the AMD OpenCL SDK with a big shared memory Xeon system. Would be nice to try the implicit optimizations of the Intel SDK under SLES.

[stele]

Me too. I need to pair this up with the NVIDIA OpenCL runtime which doesn't include native CPU support.

As for Windows, I am running Windows 7 x64 my CPU must not be supported in the alpha. I have a Q6700. I hope more CPUs will be supported in the beta - we have a ton of customers with these older, and perfectly fast, CPUs.

[ARNON_P_Intel]

We appreciate your clear requirement for Linux. This is encouraging.

Please also note that OpenCL for Intel CPUs is available with the current version of Mac OS X in the market.

[avidday]

Add my name to the list. I only use OpenCL for HPC and I only do HPC on Linux. We are big avocates of Intel's Linux toolchain, and having to go to another vendor and compiler to use OpenCL on Intel hardware is less than ideal.

[Romain_D_]

I'm also interested in OpenCL for HPC, and Linux is also our primary target. it would be great to get "OpenCL for CPU on Linux" from Intel.

[simonmcs]

It's important to recognise just how crucial Linux support will be for Intel's OpenCL offerings. I would use this today if it existed. We already have an important molecular docking code ported to OpenCL and run the same code on x86 multi-core CPUs and contemporary GPUs. We're having to use AMD's CPU OpenCL implementation on our Intel Nehalem boxes, which doesn't seem right. I'd also like to get access to Intel's OpenCL support in Vtune et al on our Linux clusters.

Come on Intel, this will open up new market opportunities for you and create another powerful way that multi- and many-core Intel processors can be used.

Simon

[elsamuko]

+1

I want to test my OpenCL code on an Intel (i3-530) Linux (Ubuntu) machine, therefore I need the SDK for it.
Hurry up, Intel.

[ARNON_P_Intel]

It is very inspiring to see such wide demand for Intels OpenCL offering on our CPUs.

Please remember that this is only a technology preview and we are doing our best to bring Linux support into our offering in future products.

By then, I will be happy to learn more about the OpenCL advantages you are seeing on Intel CPUs

• What features of OpenCL API do you use on the CPU?
• Which OpenCL extensions and optional features do you expect to see with Linux support on CPUs?
• Which of your OpenCL algorithms map better to an x86 multi-core CPU architecture?
• Do you see OpenCL as a great tool to scale your application on multi core machine, or to better utilize the SIMD instruction, or for both?
• And many other advatages you can think about...

We, at Intel, really appreciate your feedback,

Arnon

[elsamuko]

Hello Arnon,

thanks for your reply.

> What features of OpenCL API do you use on the CPU?
I'm still "playing" with OpenCL's features with an ATI card on OSX. But the Apple ATI driver is way too old (missing OpenCL1.1 support, kernel debugging fails, no cl_image support, local work size bugs). Therefore I'd like to experiment on my Linux machine with Intel CPU/GPU with newer open source drivers/SDK.

> Which OpenCL extensions and optional features do you expect to see with Linux support on CPUs?
I don't "expect" these features, it's more a wishlist:
- working kernel and env debugging with gdb
- kernel and env profiling (gDEBugger is not bad, but doesn't debug the kernel itself)
- in-kernel logging possibility
- open source drivers + sdk
- some useful ready-to-use kernels for xD buffers and images (dct, fft, convolution)
- C++ bindings and QtOpenCL integration (really, work together with these guys!)

Greetings,
elsamuko

[peteru]

I'd like to add my voice to encourage Intel to provide a Linux implementation. We have a number of clients with extensive render farms used to render movies. These are almost exclusively Linux based and our clients have told us a number of times that they will not move from Linux to an alternative operating system. At best, they may consider switching Linux distributions, but even then, they are very hesitant to do so.

Our software uses OpenCL to accelerate the rendering of visual effects. Good support for images and robust interoperability between vendors is important. At this stage, both NVidia and AMD offer Linux support, so only those vendors will be considered during any tech refresh cycles on the render farms. When Intel adds Linux OpenCL support, it will also be in the mix, providing that the Intel implementation can work side by side with AMD and NVidia in heterogenous render farms.

[ARNON_P_Intel]

Thanks,

Very interesting usages that Ive also heard from others.

Until today most public related apps were GPU only, I would like to see more ideas on how to utilize the CPU through OpenCL in these scenarios. Any directions you have?

Which kind of operability is important for you? Is that cross APIs (GL/CL/) or cross OpenCL devices (CPU/GPU/)?

[cumu]

Hi

I work into a French laboratory in acoustic sciences. We use acoustic wave simulation (noise prediction, auralization) that need a lot of memory and also a powerful process unit. The simulation is launched by a computer under Linux OS, with a lot of ram.

We are interested of using both CPU and GPU to take the advantages of each. CPU use big matrix loaded on mother board ram, then split into pieces transfered to GPU for intensive but primitive computation.

To get more information on acoustic domain, see web page of Gamma research group (another research center) http://gamma.cs.unc.edu/research/sound/

OpenCL for CPU has another benefit. We can use PyOpenCL to make the code while running. A script language that build "on the fly" a code that will be compiled then run into Cpu or Gpu.
Python is slow but very easy to write, OpenCL is very fast but hard to write.. then use both ^^

Waiting impatiently for Linux Intel OpenCL SDK.. ;)

Best regards

[pure_linux_user]

I am also disgusted to see no OpenCL support.

I am looking at embedded Linux systems, Intel seems to be building a strategic presence in mobile telephony and the Khronos group are promoting OpenCL heavily. All parties seem to concur that GPUs are the future of power-efficient mobile media processing, and Intel needs an offering.

So ... for the love of god - please hurry up and release a Linux SDK!

[peteru]

I just noticed your follow up questions - sorry for taking so long to respond...

Quoting Arnon Peleg (Intel)

I would like to see more ideas on how to utilize the CPU through OpenCL in these scenarios. Any directions you have?

CPU OpenCL support would be great as a fallback implementation in render farms where there is no GPU hardware. It would mean that our tools only need to implement compute intensive portions in OpenCL and can run everywhere. Currently we have to provide both CPU and OpenCL implementations and only use OpenCL code paths when there is support, defaulting to CPU for everything else.

Quoting Arnon Peleg (Intel)

Which kind of operability is important for you? Is that cross APIs (GL/CL/) or cross OpenCL devices (CPU/GPU/)?

We are looking at being able to take a pipeline of (GL) image processing tools, with compute intensive parts implemented in OpenCL (prefer 1.1 over 1.0) and run the OpenCL portions on any CPU or GPU in the system, distributing workload to all OpenCL devices. So, the ability to have multiple OpenCL vendors/implementations/devices, a uniform API feature set, ability to share data between OpenCL implementations/devices and of course identical results from all implementations.

[ARNON_P_Intel]

Thank you for the feedback. Appreciatethis.

We are seeing the growing demand for Linux support on this forum and hopefullyI can share with you some news soon.

[zeroreneagde]

Hi Anon,

I am programming numerical long wave equations. I currently use other graphic vendor specific OpenCLsoftware development kits for my linux development. I develop exclusively in linux at the moment, but I have begun play around with the windows based Intel OpenCL SDK, since it is the only option I have to run OpenCL on my i7 CPU. I do all of my development in C/C++, but I also link with older custom Fortran libraries for analysis to validate my own solution.

I feel that cross CPU/GPU support is more important than GL interoperability. Though, I also require GL interoperability for my visualizations written in OpenGL. The GLU nurbs interface is important to me for rigid body modeling (wave body interactions), which I would love to see optimized with OpenCL.

Some OpenCL extensions are more important than others. Double precision (and also the 64 bit atomic operations) is the most important extension. The half precision is not necessary, but significantly reduces my spatial complexity in some of my programs. The trigonometric math functions (and mod, power, sqrt, etc) are crucial to me as well for implementing my differential equations. The full extent of the OpenCL API is what attracts me to the framework. The common functions are much less important to me (min, max, radians/degrees, etc). The geometric functions are very important for both my numerical and my graphical software. The vector based relation functions are less important, though the vector load/store is important. The asynchronous functions are also important.

The heterogeneity of OpenCL is what is going to make this the base framework of almost all software. It will not be very long before we even see it used in the mobile community (< 1 year). Less time and spatial complexity from exploiting the memory access hierarchy always means less power consumption especially with the new ultra low power GPUs and CPUs. I hope that there is lots of communication with graphics and other hardware vendors as well to make sure we achieve the platform independence that is the goal of OpenCL. I look forward to seeing Intel's OpenCL contribution for the linux environment!

Glad to see that you are also seeking crowd based input!

Cheers,

Nigel