Intel Releases OpenCL SDK For Linux

[phoronix]

Phoronix: Intel Releases OpenCL SDK For Linux

Intel has released an OpenCL Software Development Kit that provides support under Linux...

http://www.phoronix.com/vr.php?view=OTQzMQ

[allquixotic]

Interesting: their "SDK" basically ships /usr/include/CL/ headers for the OpenCL language (we had these already), and a bunch of libs in /usr/lib64/OpenCL/vendors/intel. From what I can see, it ships a software-only implementation of OpenCL as /usr/lib64/libOpenCL.so which depends upon the libs in /usr/lib64/OpenCL/. It uses a couple libs with familiar names; they seem to be using the Clang compiler and a "TBB" custom heap allocator (whatever that stands for). They provide a "libOclCpuBackEnd.so", further enhancing the perception that no hardware support is available.

Kind of ironic that Intel is providing this under what seems to be a proprietary license, and it doesn't even run on Intel GPUs. What's the point of OpenCL if you aren't using the GPU? ATI and Nvidia cards are at least much closer to having OpenCL support through Gallium3d, and in the case of the binary drivers, some degree of hardware-accelerated support is already available.

Basically this is completely, utterly useless unless you want to develop programs using OpenCL and don't have a GPU with a hardware-accelerated implementation. And you won't get a good idea of your program's real-world performance on actual hardware because you will be using a CPU to do tasks that are suited for a GPU. If they really wanted to support OpenCL, they would work it into Mesa somehow. Hell, even bolting it onto the Mesa classic DRI infrastructure would be better than this "SDK" -- at least then you could use hardware OpenCL with Intel chips and possibly r300c / r600c.

I'll wait for the Gallium drivers to support OpenCL, myself. Once hardware OpenCL is available for any Gallium driver, we should see either softpipe or llvmpipe OpenCL following shortly thereafter, which would obsolete this proprietary, ad-hoc software implementation for those lacking capable hardware.

[RealNC]

Dude, this is an SDK, not a runtime. I think you're confused or something.

[sturmflut]

He's actually right, the Intel OpenCL implementation only works for Intel CPUs with SSE 4.1 or higher. No GPU support. Read the FAQ entry.

[deanjo]

It is not surprising that it is cpu only considering that intel does not have a graphics solution suitable for openCL nor do they have any real interest for openCL in a home consumer setting (they are counting on Larrabee for their HPC market). Given that Larrabee is basically a many multicore x86 their openCL implementation wouldn't be all that hard to adopt to Larrabee. When it comes down to consumer type applications that could benefit greatly from massive parallel computin intel has gone the other route by putting specialized silicon on the cpu like their hardware h264 encoding. Also don't forget that intel has just started supporting openCL over the last year and IGP wise they were somewhat limited as what they could do with their IGP's without having a license agreement on some key graphics patents which were not included in AMD's patent sharing agreement and alternative routes only became available after the Intel/Nvidia agreement. Also remember that even AMD when it first introduced openCL support it was on the CPU only.

[allquixotic]

Dude, this is an SDK, not a runtime. I think you're confused or something.

No, I just don't see the utility of an SDK that does OpenCL in software on the CPU. I mean sure, it might have some use if you have a headless build farm that auto-builds your code and you test it using a GPU-accelerated implementation, but... okay, maybe that's the use case that they're aiming for. Large corps with a Perforce server, where individual developers don't do a build, they just commit, wait 45 minutes for the build farm, then test it locally or in some kind of VM. It's not like stubbing out a fake libOpenCL for the build server would be that hard, and the headers have always been available...

It just seems that the majority of the effort that went into the development of this SDK was in producing a 100% compliant implementation against the CPU. That's nice and all, but even with SSE 4.1 and 6 cores with HT, you're not gonna come close to what a current-gen Tesla card could do in terms of parallel compute power. That's why Nvidia isn't out of business right now.

To make the OpenGL comparison: Does anyone still develop games using a software renderer to test? I highly doubt it -- they need to test against a real implementation for two big reasons. One, to make sure that the performance of their engine is within reasonable tolerances. And two, real implementations have bugs, and more often than not the app developer has to work around implementation bugs, rather than hoping that the driver will be patched. I'd be skeptical if you told me that all hardware implementations of OpenCL are released bug-free. Sure, you may be able to produce a valid binary linked against libOpenCL using this SDK, but runtime behavior (performance, correctness) is what makes or breaks a product.

I wasn't confused about what this SDK is providing, I just don't think that Michael really understood what this was. Notice in the subtitle of the headline he says "Finally"? As if the wait for OpenCL on Linux were over? Maybe it is, for lazy developers who don't know how to create a stub library, and who enjoy developing and testing code in a completely unrealistic environment. If I were working with OpenCL on Linux right now, I'd want to test against Catalyst and Nvidia's implementations of OpenCL (since the Gallium state tracker isn't complete, it isn't a contender yet). Even if your code doesn't require real-time performance like 3d rendering, it's still possible to write unacceptably inefficient code -- but if all the code you write runs slow because you're using the CPU, it's hard to compare "fast" vs "slow". If you're working with OpenCL, you probably care quite a bit about empirical profiling.

Never trust statements beginning with "in theory..." in software. Murphy's Law strikes ruthlessly in our field. Develop and test against actual implementations that your customers will use (i.e., GPGPU-accelerated). In that vein, this SDK misses the mark.

Oh, but I guess they get credit for using Clang -- another LLVM user means (hopefully) some patches will start coming in on the LLVM / Clang projects from Intel. That's not a bad thing. Or maybe the patches have already been coming in, partly as a result of the development effort on this project? Either way, I hope Intel didn't keep all their enhancements to themselves, as they'd be perfectly entitled to do under Clang's license.

[DeiF]

AFAIK OpenCL is designed for CPUs too.
It was designed to allow running of programs distributed between the GPU, CPU cores, CPUs and even other computers. It has more wide goals than CUDA.
Of course maybe I'm mistaken.

[deanjo]

AFAIK OpenCL is designed for CPUs too.
It was designed to allow running of programs distributed between the GPU, CPU cores, CPUs and even other computers. It has more wide goals than CUDA.
Of course maybe I'm mistaken.

Nope, you are correct. It was designed with CPU,GPU and DSP's in mind.

[Veerappan]

No, I just don't see the utility of an SDK that does OpenCL in software on the CPU. I mean sure, it might have some use if you have a headless build farm that auto-builds your code and you test it using a GPU-accelerated implementation, but... okay, maybe that's the use case that they're aiming for. Large corps with a Perforce server, where individual developers don't do a build, they just commit, wait 45 minutes for the build farm, then test it locally or in some kind of VM. It's not like stubbing out a fake libOpenCL for the build server would be that hard, and the headers have always been available...

It just seems that the majority of the effort that went into the development of this SDK was in producing a 100% compliant implementation against the CPU. That's nice and all, but even with SSE 4.1 and 6 cores with HT, you're not gonna come close to what a current-gen Tesla card could do in terms of parallel compute power. That's why Nvidia isn't out of business right now.

To make the OpenGL comparison: Does anyone still develop games using a software renderer to test? I highly doubt it -- they need to test against a real implementation for two big reasons. One, to make sure that the performance of their engine is within reasonable tolerances. And two, real implementations have bugs, and more often than not the app developer has to work around implementation bugs, rather than hoping that the driver will be patched. I'd be skeptical if you told me that all hardware implementations of OpenCL are released bug-free. Sure, you may be able to produce a valid binary linked against libOpenCL using this SDK, but runtime behavior (performance, correctness) is what makes or breaks a product.

I wasn't confused about what this SDK is providing, I just don't think that Michael really understood what this was. Notice in the subtitle of the headline he says "Finally"? As if the wait for OpenCL on Linux were over? Maybe it is, for lazy developers who don't know how to create a stub library, and who enjoy developing and testing code in a completely unrealistic environment. If I were working with OpenCL on Linux right now, I'd want to test against Catalyst and Nvidia's implementations of OpenCL (since the Gallium state tracker isn't complete, it isn't a contender yet). Even if your code doesn't require real-time performance like 3d rendering, it's still possible to write unacceptably inefficient code -- but if all the code you write runs slow because you're using the CPU, it's hard to compare "fast" vs "slow". If you're working with OpenCL, you probably care quite a bit about empirical profiling.

Never trust statements beginning with "in theory..." in software. Murphy's Law strikes ruthlessly in our field. Develop and test against actual implementations that your customers will use (i.e., GPGPU-accelerated). In that vein, this SDK misses the mark.

Oh, but I guess they get credit for using Clang -- another LLVM user means (hopefully) some patches will start coming in on the LLVM / Clang projects from Intel. That's not a bad thing. Or maybe the patches have already been coming in, partly as a result of the development effort on this project? Either way, I hope Intel didn't keep all their enhancements to themselves, as they'd be perfectly entitled to do under Clang's license.

Speaking from personal experience, it's much easier to debug OpenCL that is executing on a CPU than OpenCL running on a GPU. I developed most of my thesis code on AMD's Stream CPU OpenCL implementation, tested for correct algorithms/output there, and then did secondary testing and performance optimization on the Nvidia GPU implementation.

If Intel's OpenCL implementation adds any debugging/analysis tools, I'm all for trying it out. Of course, if they don't have a decent profiler included, that'll be a bit of a negative for me.

[liam]

It is not surprising that it is cpu only considering that intel does not have a graphics solution suitable for openCL nor do they have any real interest for openCL in a home consumer setting (they are counting on Larrabee for their HPC market). Given that Larrabee is basically a many multicore x86 their openCL implementation wouldn't be all that hard to adopt to Larrabee. When it comes down to consumer type applications that could benefit greatly from massive parallel computin intel has gone the other route by putting specialized silicon on the cpu like their hardware h264 encoding. Also don't forget that intel has just started supporting openCL over the last year and IGP wise they were somewhat limited as what they could do with their IGP's without having a license agreement on some key graphics patents which were not included in AMD's patent sharing agreement and alternative routes only became available after the Intel/Nvidia agreement. Also remember that even AMD when it first introduced openCL support it was on the CPU only.

Ivybridge will support ocl.
Btw I thought larrabee was utterly doa?