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.
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.
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.
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,
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!)
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.
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/)?
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.. ;)
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!
Quoting Arnon Peleg (Intel)
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.
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.