Package Details: intel-opencl-sdk 2020.1.395-2

Git Clone URL: (read-only, click to copy)
Package Base: intel-opencl-sdk
Description: Intel SDK for OpenCL Applications
Upstream URL:
Licenses: custom:intel
Submitter: big_gie
Maintainer: None
Last Packager: dankamongmen
Votes: 84
Popularity: 0.002616
First Submitted: 2011-05-13 13:53 (UTC)
Last Updated: 2020-05-27 18:30 (UTC)

Latest Comments

mookins commented on 2020-06-16 05:13 (UTC) (edited on 2020-06-16 05:33 (UTC) by mookins)

The URL listed in the PKGBUILD is incorrect for the sha256 checksum given. is for CentOS operating systems and has the SHA256 checksum of 758078ac0cf12061b97cbde4692e886cf930ca96a92ba7dfb9c71dcce1b243f6. id the package for Ubuntu and has the SHA256 checksum of 4b8a1e39888e9fb13f717ea6f91aaf6ae8677043ff59a95767fb2f5d10f73850 which agrees withe PKGBUILD.

Changes I made can be found at

zezadas commented on 2020-05-26 14:13 (UTC)

cpio is a dependency. please update deps.

dankamongmen commented on 2020-01-05 02:31 (UTC)

@ava1ar I'm interested in taking over this package. I maintain ~7 packages now, and am familiar with this one.

ava1ar commented on 2019-08-16 06:20 (UTC) (edited on 2019-08-16 06:20 (UTC) by ava1ar)

Packaging for version 2019 completely changed - now there is a GUI installer inside the package.

I don't have time to work on new PKGBUILD. Anyone interested to help?

New version is 2019.3.208

URL is${pkgver}.tar.gz

ava1ar commented on 2018-11-01 04:58 (UTC)


Package updated, thanks for the patch.

alexbrinister commented on 2018-08-14 00:04 (UTC) (edited on 2018-08-14 00:24 (UTC) by alexbrinister)

I get the following output after installing:

alexbrinister@alexbrinister-OryxPro ~ % ioc
/usr/sbin/ioc: line 9: /opt/intel/opencl-sdk/bin/ioc64.bin: No such file or directory

I think sdk_dir in ioc64 needs to be linked to the SDK directory instead of the top-level one. Patch:

ava1ar commented on 2018-01-31 09:42 (UTC)

Updated to 2017_7.0.0.2568 (thanks pedromundo for updated PKGBUILD)

Please note, I did NOT include for OpenCL 2.1 - if you want it, please modify PKGBUILD before installing and uncomment corresponding lines (you may not need intel-opencl-runtime in this case, but this is not verified).

commented on 2018-01-30 19:45 (UTC)



pedromundo commented on 2017-09-27 19:22 (UTC) (edited on 2017-09-27 19:23 (UTC) by pedromundo)

A heads-up for anyone that needs to use the latest version for OpenCL 2.1 support or whatever reason: I got it working by removing both the intel-opencl and intel-opencl-runtime and then changing the pkgbuild slightly to compensate for changes in the .tgz (the latest version includes an experimental for OpenCL 2.1, thus I'm not sure where intel-opencl-runtime should still be a dependency) Below is my (somewhat hackish) PKGBUILD for 2017. (tested to not break things with nvidia OpenCL, but I didn't test with intel gpu OpenCL, since I don't have access to a machine with IGP right now), feedback welcome. # Maintainer: ava1ar <> # Contributor: Daniel Nagy <danielnagy at gmx de> # Contributor: Nicolas Bigaouette <> # Contributor: Vojtech "kralyk" Kral pkgname=intel-opencl-sdk pkgver=2017_7.0.0.2511 releasever=11705 pkgrel=1 pkgdesc="Intel SDK for OpenCL Applications" arch=('x86_64') url="" license=('custom:intel') depends=('opencl-icd-loader' 'libpng12' 'opencl-headers') optdepends=('intel-opencl-runtime: OpenCL runtime for Intel Core and Xeon processors') install=intel-opencl-sdk.install source=(${releasever}/intel_sdk_for_opencl_${pkgver}_x64.tgz) sha256sums=('8276bc9e4df2beb408014b169f604637dd83f465461bb0c61a7a99edbf03b740') package() { cd "${srcdir}"/intel_sdk_for_opencl_${pkgver}_x64/ # Copy license install -Dm644 EULA.txt "${pkgdir}"/usr/share/licenses/intel-opencl-sdk/license # Unpack rpms for i in rpm/*.rpm; do bsdtar -xf "$i"; done # Install files mkdir -p "${pkgdir}/opt/intel/opencl-sdk" cp -r opt/intel/opencl/* "${pkgdir}/opt/intel/opencl-sdk" # Register ICD mkdir -p "${pkgdir}/etc/OpenCL/vendors" echo "/opt/intel/opencl-sdk/exp-runtime-2.1/lib64/" > "${pkgdir}/etc/OpenCL/vendors/intel.icd" # Cleanup rm -rf "${pkgdir}"/opt/intel/opencl-sdk/uninstall* # Fix runtime_lib_dir and sdk_dir sed -i -e 's|/etc/alternatives/opencl-intel-tools|/opt/intel/opencl-sdk|g' \ -e 's|$(dirname $(readlink /etc/alternatives/|/opt/intel/opencl-runtime/lib64|g' \ "${pkgdir}"/opt/intel/opencl-sdk/SDK/bin/{KBServer64,ioc64} # Symlink binaries mkdir -p "${pkgdir}/usr/bin" ln -s "/opt/intel/opencl-sdk/SDK/bin/ioc64" "${pkgdir}/usr/bin/ioc" }

ailick commented on 2017-09-03 02:50 (UTC)

New Version

ava1ar commented on 2016-12-10 04:39 (UTC)

Replaced libcl dependency wuth opencl-icd-loader. Please let me know if you have better solution. Thanks!

mmozeiko commented on 2016-12-08 23:20 (UTC) (edited on 2016-12-08 23:22 (UTC) by mmozeiko)

opencl-driver metapackage is for actual driver, not the library that applications need to link with ( file). Driver is the one that depends on your GPU/CPU (nvidia, intel, ...). OpenCL ICD loaded is platform independent code that loads library installed by driver.

kjslag commented on 2016-12-08 05:33 (UTC)

ocl-icd 2.2.9-1 provided libcl. For some reason ocl-icd 2.2.9-2 does not, but instead optionally depends on opencl-driver.

mmozeiko commented on 2016-12-08 05:22 (UTC)

I believe libcl in PKGBUILD for this package needs to be replaced with opencl-icd-loader.

chappjc commented on 2016-12-08 00:43 (UTC) (edited on 2016-12-08 00:44 (UTC) by chappjc)

I have this already installed and now on system upgrade pacman is complaining that: intel-opencl-sdk: installing ocl-icd (2.2.9-2) breaks dependency 'libcl' But ocl-icd replaces libcl as far as I can tell, and I don't have libcl in any package list. I got intel-opencl-sdk installed on my system without any issue. After removing intel-opencl-sdk, pacman -Su worked fine. Dunno yet if I can reinstall this package...

ava1ar commented on 2016-12-01 04:01 (UTC)

rpmextract removed, bsdtar is used instead

Scimmia commented on 2016-11-24 06:25 (UTC)

Nope, not necessary at all.

kjslag commented on 2016-11-22 02:48 (UTC) also calls the rpm2cpio script, which looks rather nontrivial. Is rpm2cpio not necessary?

Scimmia commented on 2016-11-22 02:44 (UTC)

This should use bsdtar to extract the rpm files; all does is call bsdtar, so it's a useless makedep when makepkg already requires bsdtar.

aza commented on 2016-09-30 19:12 (UTC)

sdk version changed and the old one isn't there anymore, that's why the hash doesn't match, edit the PKGBUILD version: 2016_6.2.0.1761 hash: cf6c575fb2fe5ce38d08f286eb7fd45fec7263f700788c4dc6a6bf9b13ec368c

deyannis commented on 2016-09-16 12:16 (UTC)

The latest version (2016-08-29 03:03) has a wrong hash. Also intel_sdk*/ is missing from /src

ava1ar commented on 2016-04-28 23:58 (UTC)

That is why I was asking about the headers compatibility. OK, I reverted the deletion of the headers and they are copied now, but in the opt dir. So, package still depends on opencl-headers, but keeps intel headers, since they have some extra stuff there.

kjslag commented on 2016-04-28 19:24 (UTC)

Arch's version of cl_ext.h comes directly from the official source ( I think Intel needs to talk to Khronos to get their extensions added officially, which I think is also how things work for opengl. I doubt that the opencl-headers maintainers will want to apply a patch to add Intel's (currently) unofficial extensions, but you can try asking if you like.

misc commented on 2016-04-28 18:06 (UTC) (edited on 2016-04-28 18:49 (UTC) by misc)

We could, but for laziness resp. compatibility – as it would require no code changes and have no negative effect on non-Intel-SDK users – I'd prefer pinging the Arch maintainer. (Dunno about the beignet issue, but he could also just add these.) edit: Also, shouldn't there be a file in /etc/ with /opt/intel/opencl-sdk/lib64 in it (resp. another for intel-opencl-runtime with /opt/intel/opencl-runtime/lib64)? At least the CUDA packages add those. Either way, I get an instant sigsegv in cl::Context with the Intel runtime, great. Currently in contact with support.

kjslag commented on 2016-04-28 17:56 (UTC)

Could we keep Intel's headers in the /opt directory? Then if you want Intel's extensions, you can include the /opt headers in your code instead.

misc commented on 2016-04-28 17:49 (UTC)

Damn, I'd also very much prefer the unified opencl-headers solution (esp. as some are newer), but there's an issue with cl_ext.h: While Arch's version includes the 2.1 ones, it doesn't contain all of Intel's extensions. (beignet suffers from a similar issue, its cl_d3d10.h, cl_d3d11.h, cl_dx9_media_sharing.h and cl_intel.h are missing entirely: ) Dunno how to resolve this, maybe the Arch maintainer could add what's missing? diff: (guess about top half can be ignored as it's Windows only)

kralyk commented on 2016-04-28 13:19 (UTC)

Ok, so the backend has been split off into another package, didn't know that, thanks. As for the headers, they are defined by the OpenCL standard, so they shouldn't differ significantly. IMHO adding opencl-headers as a dependency should be fine.

ava1ar commented on 2016-04-28 02:46 (UTC)

Updated. Please take a look now.

pavanky commented on 2016-04-28 00:14 (UTC)

@ava1ar That would be greatly appreciated! I currently have to modify PKGBUILD manually to fix the issue. Looks like you are going to take care it!

ava1ar commented on 2016-04-27 18:10 (UTC)

Thanks, @kjslag! OK, in next update (will be posted later today) I am going to make the package dependent on opencl-headers and also will not copy the headers in the intel-opencl-sdk. This should make it compatible with beignet package. Please let me know if there are any objections.

kjslag commented on 2016-04-27 18:06 (UTC)

The only difference between the headers is that opencl-headers are more up to date. They are certainly all compatible. The opencl-headers package exists so that packages like intel-opencl-sdk can add them as a depends, and this is what every other opencl sdk package does.

ava1ar commented on 2016-04-27 03:01 (UTC)

Anybody know if the headers, provided by opencl-headers, intel-opencl-sdk and beignet are same? (or compatible?) If yes, I can just not include headers to the package and make if dependable of opencl-headers.

kjslag commented on 2016-04-27 02:49 (UTC)

Thanks ava1ar. Unfortunately this package now conflicts with beignet because both packages (incorrectly) provide opencl-headers. intel-opencl-sdk (and beignet) should instead depend onopencl-headers. See

ava1ar commented on 2016-04-26 18:17 (UTC) (edited on 2016-04-26 18:18 (UTC) by ava1ar)

- Will add opencl-headers to provides section with next update (coming later today) - @kralyk, as @mmozeiko mentioned, you should install intel-opencl-runtime, which will serve as CL backend - it will register the IDC during installation.

mmozeiko commented on 2016-04-26 17:51 (UTC)

Yes, having opencl-headers in "provides" is much better option! @kralyk: Should intel-opencl-sdk should provide CL backend? My understanding is that it is SDK, for development. Backend is in intel-opencl-runtime package.

NinjaKoala commented on 2016-04-26 14:25 (UTC)

@ava1ar @kralyk As an alternative, opencl-headers could be added to the provides section, then the dependencies wouldn't break.

kralyk commented on 2016-04-26 08:22 (UTC)

Sorry, typo: the header files should _NOT_ have been put into /usr/include

kralyk commented on 2016-04-26 08:20 (UTC)

@ava1ar @misc IMO the header files should have been put into /usr/include, there should be no conflict. Packages depending on OpenCL depend on opencl-headers, not intel-opencl-sdk directly. Also, @ava1ar, why did you remove the ICD registration? How are programs supposed to load intel-opencl-sdk backend?

mmozeiko commented on 2016-04-26 02:45 (UTC)

The latest update (2016-2) now is in conflict with beignet: :: intel-opencl-sdk and beignet are in conflict (opencl-headers). Remove beignet? [y/N] How to have intel-opencl-sdk installed in parallel with beignet? Without beignet I don't have GPU OpenCL acceleration. With 2016-1 package installed I can have beignet installed and I can use both - GPU and CPU for OpenCL.

ava1ar commented on 2016-04-26 02:06 (UTC)

@misc Thanks for report. I update the PKGBUILD, however, since opencl-headers also install headers to the /usr/include, I added opencl-headers to conflics section.

misc commented on 2016-04-25 17:02 (UTC) (edited on 2016-04-25 18:11 (UTC) by misc)

The headers need to find their way into /usr/include (like beignet does), not /opt/intel/opencl-sdk/include, or otherwise sources relying on the standard paths fail to compile.

ava1ar commented on 2016-04-23 00:25 (UTC)

Hi, a took the ownership over the package and updated to the latest version. I cleaned up PKGBUILD and revisited all dependencies. Since I am mostly interested in runtime, active users of SDK - please report any issues, related to package and PKGBUILD. Thanks.

chris64 commented on 2016-04-01 12:06 (UTC)

Thank you @satriani. Did anyone try to run the PKGBUILD on the new CentOS tarball? Maybe we're lucky and and it just works?

satriani commented on 2016-02-16 15:15 (UTC) (edited on 2016-02-16 15:22 (UTC) by satriani)

Time for neu Source: Intel® SDK for OpenCL™ Applications for CentOS: or Intel® SDK for OpenCL™ Applications for Ubuntu:

dthpham commented on 2015-08-16 03:13 (UTC)

@pavanky I just resubmitted intel-opencl-runtime to the AUR. But note that I'm not the original maintainer of the package and am not that familiar with it at all. I will disown it if there's a person out there who has any interest in maintaining it.

pavanky commented on 2015-08-10 12:58 (UTC)

Installing this package does not install required by icd. I think it is installed by the "intel-opencl-runtime" package. That package is no longer in aur4. @drevilt Do you plan to maintain the other package as well.

yan12125 commented on 2014-11-23 06:07 (UTC)

Well, I add the "-I/opt/intel/opencl-sdk/include" flag in the Makefile of my opencl application. It just works fine.

kralyk commented on 2014-11-18 18:49 (UTC)

@yan12125 Well, you probably still need them to develop, don't you?

yan12125 commented on 2014-11-18 16:52 (UTC)

opencl-headers is not required because necessary files already provided in Intel's package. (/opt/intel/opencl-sdk/include/)

commented on 2014-10-11 09:53 (UTC)

Hi, I think you didn't take the good link, as it actually download the runtime and not the sdk!

cguenther commented on 2014-10-02 21:59 (UTC)

Yes, the links are online and start downloading without registration.

Ginkgo commented on 2014-09-30 22:40 (UTC)

Yeah, the whole registration thing sucks. Do these links work for you?

nagy commented on 2014-09-30 17:40 (UTC)

again without registering i cannot find a downloadlink. can someone please provide one? if somebody wants to maintain this package i can orphan it.

Ginkgo commented on 2014-09-29 23:18 (UTC)

There's version 2014 R2 with OpenCL 2.0 support out now.

radioxoma commented on 2014-09-05 18:38 (UTC)

@drevilt, just add to PKGBUILD ln -s "${_ipath}/bin/KernelBuilder64" "${pkgdir}/usr/bin/KernelBuilder64" ln -s "${_ipath}/bin/KBServer64" "${pkgdir}/usr/bin/KBServer64" And run script $ KernelBuilder64 instead of this binary cd /opt/intel/opencl-sdk/bin/ $ ./KernelBuilder64.bin

nagy commented on 2014-09-04 21:40 (UTC)

the error occuring in KernelBuilder64 is: /opt/intel/opencl-sdk/bin/KernelBuilder64.bin: /usr/lib/ no version information available (required by /opt/intel/opencl-sdk/bin/KernelBuilder64.bin) terminate called after throwing an instance of 'std::string' I dont know how to fix this.Does anybody have an idea ?

radioxoma commented on 2014-09-04 15:04 (UTC)

Please, add libpng12 to dependency list. Also it's not possible to run KernelBuilder64 from terminal or by an menu icon.

malaggan commented on 2014-07-05 02:46 (UTC)

The missing file /opt/intel/opencl-sdk/lib64/ is found in the AUR package intel-opencl-runtime.

Palmik commented on 2014-06-22 13:26 (UTC)

Hi. I have installed intel-opencl-sdk version 2014_R1-2, the /etc/OpenCL/vendor/intel.icd points to /opt/intel/opencl-sdk/lib64/ which does not exist.

ImperialDwarf commented on 2014-06-03 13:05 (UTC)

sha256 for current version: 21eb9a53c7f96ec1cbc38e88165da911a9c823c256932425837f9ada517d6d8f

danfunky commented on 2014-05-23 13:40 (UTC)

sdk: runtime:

nagy commented on 2014-05-23 13:05 (UTC)

i cannot find a new downloadlink without having to register. does someone have a link to this?

kralyk commented on 2013-12-03 06:21 (UTC)

Great! Thanks.

nagy commented on 2013-12-01 20:34 (UTC)

i think i can take this as i am using this tool myself.

kralyk commented on 2013-12-01 18:33 (UTC)

Hello everyone. Sadly due to decreasing amount of free time I am unable to maintain the package any longer. Therefore I'm disowning intel-opencl-sdk. Feel free to adopt this package if you're willing to maintain it. Regards, VK

applebloom commented on 2013-11-27 10:58 (UTC)

jellysheep So basically, if I have a Sandy Bridge Core i7, this is worthless for me?

ayresdl commented on 2013-10-03 16:22 (UTC)

version 2013 R2 is out

zhehao commented on 2013-08-02 03:14 (UTC)

Oh, also, it seems like the ioc64 program has been replaced with a shell script that sets up the dynamic linker path before calling ioc64.bin, but the path is wrong. You'll also want to add the following line somewhere in the package() function. sed -i s/opencl-1.2-3.0.67279/opencl-sdk/ "${pkgdir}/${_ipath}/bin/ioc64"

zhehao commented on 2013-08-02 02:56 (UTC)

The symlink at the end of PKGBUILD is incorrect. The main binary is at /opt/intel/opencl-sdk/bin/ioc64, not /opt/intel/opencl-sdk/ioc64. You should make the following change on the last line of the package function -ln -s "${_ipath}/ioc64" "${pkgdir}/usr/bin/ioc" +ln -s "${_ipath}/bin/ioc64" "${pkgdir}/usr/bin/ioc"

jellysheep commented on 2013-05-30 18:41 (UTC)

The Intel OpenCL SDK 2013 under linux runs OpenCL kernels only on the Xeon processors and Xeon Phi coprocessors. Do the package maintainers know this fact and doesn't it make sense to wait for the 2013 SDK until it supports running on all 64 bit CPUs (I don't know, it's only a suggestion)? However, thanks for maintaining this package.

kralyk commented on 2013-05-24 19:22 (UTC)

Updated. Alas, iocgui seems to be gone. Also, I'm not sure which files are needed and which not, so I made it install the whole thing in /opt just like it's in the rpms. Hope it works. If you run into any trouble with the new version, feel free to report/suggest here.

kralyk commented on 2013-05-24 18:56 (UTC)

Hang on guys, I'm updating, they changed the structure...

nagy commented on 2013-05-22 20:23 (UTC)

i think because iocgui requires java this package should get an optional dependency to "java-runtime"

kralyk commented on 2013-04-03 12:45 (UTC)

Ok, should be fixed now. Also the script is linked as just "iocgui" now...

maleadt commented on 2013-04-03 12:08 (UTC)

iocgui doesn't find the jar: $ ERROR: could not find ioc.jar I think because INTELOCLSDKROOT points to /usr/lib64/OpenCL/vendors/intel rather than /opt/intel/opencl-sd (in

kralyk commented on 2013-01-14 12:29 (UTC)

@sl1pkn07: There's no reason to install with this package. As explained earlier, this pkg only concerns Intel OpenCL _backend_ implementation. is _not_ part of that, it's a common loader (ICD Loader). Intel's has to my best knowledge no advantages over the other ones and would only cause unecessary conflicts.

sl1pkn07 commented on 2013-01-14 07:41 (UTC)

question about (opencl in general, i'm really noob) libcl[extra] is provide by nvidia (see [1]) if have ATI/AMD, if install opencl-catalyst[community] replaces libcl(remove) and install provide by AMD (see [2]) by this package don't have conflicts with Nvidia/AMD-ATI provide by libcl installed by dependencies? or intel use nvidia/ATI-AMD implementation by this package should not remplace nvidia/AMD-ATI implementation by symlink from /opt/intel/opencl-sdk/ to /usr/lib (and add libcl to conflicts) ? i'm not sure, i think the provide by Nvidia, ATI/AMD and Intel is not same greetings [1] [2]

kralyk commented on 2012-11-15 12:25 (UTC)

@petRUShka: Nope, it should NOT provide libcl. If you notice, it rather depends on libcl, since this package is an implementation of OpenCL (a backend, if you will), whereas libcl is OpenCL ICD loader, a library that manages implementations (backends) and provides enumeration of them.

petRUShka commented on 2012-11-07 09:15 (UTC)

It should provide 'libcl' like AMD version (, and Nvidia version ( do.

kralyk commented on 2012-05-23 23:16 (UTC)

Updated. Sorry for the delay. Feel free to test.

xico commented on 2012-05-08 22:43 (UTC)

Version 2012 is out.

commented on 2012-02-16 11:38 (UTC)

Is it possible to include in this installation the ioc (intel offline compiler)? It is located within the rpm at lib64/OpenCL/vendors/intel/* (Especially Regards

czk commented on 2011-12-22 21:30 (UTC)

This PKGBUILD actualy downloads intel_ocl_sdk_1.1_beta_lnx_64.rpm from, but just forces a different name on the file when it's saved. The intel_ocl_sdk_1.5_x64.rpm is available (as a gzipped tar) at

commented on 2011-12-16 11:46 (UTC)

I found a bug within while using the Intel OpenCL SDK and I reported it to Intel: They said that: 'Specifically, there may be libc differences in Arch Linux which cause this problem' Could somebody try 'printf' within his OpenCL kernel and report this behaviour?

big_gie commented on 2011-10-19 13:57 (UTC)

I had trouble with clinfo too a couple of days earlier. It was aborting when calling OpenCL 1.1 functions/properties on my nvidia installation (it had to be recompiled with something defined, was it OpenCL_1_1 or something like that?) Intel's driver is kind of crap... try to run a code (maybe just clinfo, or my (shameless plug)) under valgrind and just see... AMD APP had a lot of errors too iun 2.3, 2.4 days, but 2.5 is a lot better.

kralyk commented on 2011-10-19 13:28 (UTC)

Updated. clinfo still shows errors while reading intel opencl info, but this was in previous versions too. Maybe it's clinfo bug, I dont know...

big_gie commented on 2011-10-18 19:39 (UTC)

Sorry, version 1.5

big_gie commented on 2011-10-18 19:39 (UTC)

Version 1.6 came out September 26th.

kralyk commented on 2011-08-04 16:02 (UTC)

It would be great if it worked. Someone needs to test this and that someone is probably me :D

commented on 2011-08-02 16:48 (UTC)

I've tried to show that using nVidia's old libcl instead of new AMD's libopencl won't lock user only to OpenCL 1.0 when using Intel SDK (as mentioned by kralyk). nVidia surely doesn't officially support stable 1.1 version (they have many other goals like CUDA), but I've hear that there are some pre-release builds with 1.1 libraries. Haven't verified this, though.

big_gie commented on 2011-08-02 13:56 (UTC)

It is expected that OpenCL v1.1 will fail on nvidia cards. So the question is, can coming from nvidia can expose 1.1 features without crashing? I doubt that, but haven't tested it myself.

commented on 2011-08-02 13:53 (UTC)

Well, about OpenCL versions - it's quite strange. I got platform info about my nVidia card and Intel CPU using oclDeviceQuery utility from CUDA SDK. And it says that nVidia card uses 1.0 version, but Intel - 1.1 (that's from CL_PLATFORM_VERSION, CL_DRIVER_VERSION and CL_DEVICE_OPENCL_C_VERSION). Also, I tried to use some functions of OpenCL 1.1 with libcl from [extra] on Intel CPU. Specifically, it was 3-vector support (I was testing double3 with '#pragma OPENCL EXTENSION cl_khr_fp64 : enable'). It worked flawlessly, while on nVidia it failed. So the issue about libcl might not be that bad because Intel SDK uses (seemingly) its completely own OpenCL 1.1 library.

kralyk commented on 2011-08-01 11:28 (UTC)

(typo: split off of nvidia-utils)

kralyk commented on 2011-08-01 08:30 (UTC)

Guys, please... First of all, I updated the libcl dependency (obviously). We talked about this on mailing list. The libcl pkg is new. It's been slip off of nvidia-utils. But please note that the choice really is not that simple as you might think, because libcl (ie the nvidia ICD, the one in repos) is _OUTDATED_. The nVidia ICD loader only conforms to OpenCL 1.0 standard, while the ICD from AMD (libopencl pkg from AUR) is of version 1.1. The reason why nVidia ICD is in repos rather than the AMD one is that the AMD one has restrictive license upon it and cannot be pushed in repos cause of that. So the choice is really up to you now - Either you can use the libcl from repos (nvidia, outdated) and so be able to install all three SDKs at the same time but with some possible limitations and/or bugs with OpenCL 1.1 features in Intel and AMD SDK. OR you can use the AMD libcl (libopencl, from aur) without nvidia, which enables you to use OpenCL version 1.1 in all it's glory. Of course, the best sollution would be to persusade nVidia to update to OCL 1.1 or AMD to switch to less restrictive license, but who really wants to talk to them about this? Most probably they won't agree to do so... So the choice is yours to pick. The libopencl pkg from AUR provides 'libcl' (it always has), so it's no problem to pick either one. Thanks for the .pch, that was bugged... Also the pkg is in /opt because intel sdk doesn't follow linux/unix filesystem and dependency standards very well (as usual).

monson commented on 2011-08-01 02:24 (UTC)

I agree with yl3gdy, and libcl has already provided so needn't install it again. And I don't know why it has to be install in /opt , since the default prefix in the package is /usr .

commented on 2011-07-31 19:24 (UTC)

Well, it would be great to replace libopencl dependency with libcl as long as libcl is more neutral. libopencl conflicts with nvidia-utils, but libcl conflicts with nothing (and it works here), that is a pity for nvidia owners. Also here opencl_.pch file is required to build a kernel which isn't copied. Here is an updated PKGBUILD (11th line - dependencies, 30th line - added PCH file copying):

kralyk commented on 2011-07-08 13:34 (UTC)

Dependency bugfix. Hope it's ok.

kralyk commented on 2011-07-07 01:49 (UTC)

Ok, it's been updated. Feel free to test. (Please don't report the conflicting, I'm working on a sollution. I have to talk about that with TUs, it'll take some more time)

kralyk commented on 2011-07-06 22:17 (UTC)

Hello big_gie, and others. First of all, sorry for the huge delay and inactivity on my part in last like month or so. It was mainly due to uni, which was giving me really hard times (exams, etc...). Also some personal troubles, don't mind that. Anyways, I'm back now and ready to roll. I'll be updating this pkg tonight.

big_gie commented on 2011-07-06 21:18 (UTC)

See for an updated version. Bumped to 1.1 final. Also, re-organized the install paths. kralyk, you might want to review that. But one thing is sure, putting everything in /etc/OpenCL/vendors/intel is broken. /etc/OpenCL/vendors needs to have only the .icd file. So I've placed all the rest in /opt/intel/opencl-sdk. I just tested it alongside amdstream. There still need to be one somewhere: I don't know how one can link with amdstream's but run using Intel's driver... Maybe is just generic and the .icd file is really what choose the implementation to run on? My OpenCL code works with this. This is good news ;) Also kralyk, when we add the path to /etc/*.conf, there is no need for the .so file to be in /usr/lib{,64}. I placed intel's one in /opt/intel/opencl-sdk/usr/lib64/. Maybe this could be done with amdstream too? Place everything in /opt/amdstream instead of /usr/lib?

big_gie commented on 2011-05-22 17:10 (UTC)

Hi kralyk, any update on this? Thanks! :)

kralyk commented on 2011-05-13 21:53 (UTC)

Everyone please have patience, fixed pkg is being made :)

kralyk commented on 2011-05-13 15:38 (UTC)

Okay, few tips: → you don't need the entry → in /etc/OpenCL/vendors should be only one file "intelocl64.icd" (not directory) containing the intel so name - "" → .so files should go in /usr/lib (not lib64) and they should be symlinked properly, not the way it's done in rpm (or maybe it's the extracotr fault). (See amdsteram) → I'm not sure about the .rtl files, but I think they can go to /usr/lib as well → don't install "llc" at all, instead add 'llvm' in dependencies → use the install command instead of cp (along with correct permissons, see man install) → omit the include directory entirely, we don't need d3d10 stuff on linux afaik Hope everything works for ya ;-)

big_gie commented on 2011-05-13 15:29 (UTC)

Ok I fixed the ICD, or I think I did. My code still fails with: open("/etc/OpenCL/vendors/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 5 getdents(5, /* 3 entries */, 32768) = 80 getdents(5, /* 0 entries */, 32768) = 0 close(5) = 0 write(1, " Error -1001 in clGetPlatformIDs"..., 42 Error -1001 in clGetPlatformIDs Call !!! ) = 42 write(1, "ERROR calling oclGetPlatformID()"..., 80ERROR calling oclGetPlatformID() (src/OclUtils.cpp line 178): Unspecified Error ) = 80 write(3, " Error -1001 in clGetPlatformIDs"..., 122) = 122 rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0 tgkill(23380, 23380, SIGABRT) = 0 Any idea?

big_gie commented on 2011-05-13 14:55 (UTC)

Ok got it, strace revealed what needed to be done.

big_gie commented on 2011-05-13 14:53 (UTC)

Are you talking about $srcdir/usr/lib64/OpenCL/vendors/intel/intelocl64.icd that would need to be in /etc?

kralyk commented on 2011-05-13 14:46 (UTC)

Ah, never mind, found the ICD, but you need to install that in /etc anyway...

kralyk commented on 2011-05-13 14:45 (UTC)

The RPM is kind of empty... Where is the ICD registration for example? And OpenCL shared object (

big_gie commented on 2011-05-13 14:07 (UTC)

I can't run my code though. I can't obtain a platform calling clGetPlatformIDs(): Error -1001 in clGetPlatformIDs Call !!! ERROR calling oclGetPlatformID() (src/OclUtils.cpp line 178): Unspecified Error Aborted

kralyk commented on 2011-05-13 14:04 (UTC)

Oh I see you made the pkg. I was just about to make it :D

big_gie commented on 2011-05-13 13:54 (UTC)

New Intel's OpenCL SDK. See github ( ) for latest version.