Package Details: intel-opencl-sdk 2016-5

Git Clone URL: https://aur.archlinux.org/intel-opencl-sdk.git (read-only)
Package Base: intel-opencl-sdk
Description: Intel SDK for OpenCL Applications
Upstream URL: https://software.intel.com/en-us/intel-opencl/download
Licenses: custom:intel
Submitter: big_gie
Maintainer: ava1ar
Last Packager: ava1ar
Votes: 81
Popularity: 3.331271
First Submitted: 2011-05-13 13:53
Last Updated: 2016-04-28 23:56

Latest Comments

ava1ar commented on 2016-04-28 23:58

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

Arch's version of cl_ext.h comes directly from the official source (https://www.khronos.org/registry/cl/). 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

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/ld.so.conf.d 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

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

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: https://cgit.freedesktop.org/beignet/tree/include/CL )

Dunno how to resolve this, maybe the Arch maintainer could add what's missing?
diff: http://pastebin.com/raw/cQU2XcAe (guess about top half can be ignored as it's Windows only)

kralyk commented on 2016-04-28 13:19

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

Updated. Please take a look now.

pavanky commented on 2016-04-28 00:14

@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

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

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

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

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 https://www.diffchecker.com/4n8cmmxp

ava1ar commented on 2016-04-26 18:17

- 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

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

@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

Sorry, typo:

the header files should _NOT_ have been put into /usr/include

kralyk commented on 2016-04-26 08:20

@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

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

@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

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

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

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

Time for neu Source:
Intel® SDK for OpenCL™ Applications for CentOS: http://registrationcenter-download.intel.com/akdlm/irc_nas/8522/intel_sdk_for_opencl_2016_6.0.0.1049_x64.tgz
or
Intel® SDK for OpenCL™ Applications for Ubuntu: http://registrationcenter-download.intel.com/akdlm/irc_nas/8555/intel_sdk_for_opencl_2016_ubuntu_6.0.0.1049_x64.tgz

dthpham commented on 2015-08-16 03:13

@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

Installing this package does not install libintelopencl.so 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

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

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

yan12125 commented on 2014-11-18 16:52

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

Piou commented on 2014-10-11 09:53

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

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

Ginkgo commented on 2014-09-30 22:40

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

http://registrationcenter.intel.com/irc_nas/4667/intel_sdk_for_ocl_applications_2014_ubuntu_4.6.0.92_x64.tgz
http://registrationcenter.intel.com/irc_nas/4667/intel_sdk_for_ocl_applications_2014_4.6.0.92_x64.tgz
http://registrationcenter.intel.com/irc_nas/4181/opencl_runtime_14.2_x64_4.5.0.8.tgz

drevilt commented on 2014-09-30 17:40

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

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

radioxoma commented on 2014-09-05 18:38

@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

drevilt commented on 2014-09-04 21:40

the error occuring in KernelBuilder64 is:

/opt/intel/opencl-sdk/bin/KernelBuilder64.bin: /usr/lib/libOpenCL.so.1: 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

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

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

Palmik commented on 2014-06-22 13:26

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

ImperialDwarf commented on 2014-06-03 13:05

sha256 for current version: 21eb9a53c7f96ec1cbc38e88165da911a9c823c256932425837f9ada517d6d8f

danfunky commented on 2014-05-23 13:40

sdk: http://registrationcenter.intel.com/irc_nas/4181/intel_sdk_for_ocl_applications_2014_4.4.0.117_x64.tgz

runtime:
http://registrationcenter.intel.com/irc_nas/4181/opencl_runtime_14.1_x64_4.4.0.117.tgz

drevilt commented on 2014-05-23 13:05

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

Great! Thanks.

drevilt commented on 2013-12-01 20:34

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

kralyk commented on 2013-12-01 18:33

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

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

ayresdl commented on 2013-10-03 16:22

version 2013 R2 is out http://software.intel.com/en-us/vcsource/tools/opencl-sdk-xe

zhehao commented on 2013-08-02 03:14

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

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

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

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

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

drevilt commented on 2013-05-22 20:23

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

kralyk commented on 2013-04-03 12:45

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

maleadt commented on 2013-04-03 12:08

iocgui doesn't find the jar:
$ iocgui.sh
ERROR: could not find ioc.jar

I think because INTELOCLSDKROOT points to /usr/lib64/OpenCL/vendors/intel rather than /opt/intel/opencl-sd (in iocgui.sh)

kralyk commented on 2013-01-14 12:29

@sl1pkn07: There's no reason to install libOpenCL.so with this package. As explained earlier, this pkg only concerns Intel OpenCL _backend_ implementation. libOpenCL.so is _not_ part of that, it's a common loader (ICD Loader). Intel's libOpenCL.so 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

question about libOpenCL.so (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 libOpenCL.so provide by AMD (see [2])

libpenCL.so by this package don't have conflicts with Nvidia/AMD-ATI libOpenCL.so provide by libcl installed by dependencies? or intel use nvidia/ATI-AMD implementation

libOpenCL.so by this package should not remplace nvidia/AMD-ATI implementation by symlink from /opt/intel/opencl-sdk/libOpenCL.so to /usr/lib (and add libcl to conflicts) ?

i'm not sure, i think the libopencl.so provide by Nvidia, ATI/AMD and Intel is not same

greetings

[1] https://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/libcl)
[2] https://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/catalyst-utils#n115

kralyk commented on 2012-11-15 12:25

@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

It should provide 'libcl' like AMD version (https://aur.archlinux.org/packages/libopencl/, https://aur.archlinux.org/packages/catalyst-utils/) and Nvidia version (https://www.archlinux.org/packages/extra/i686/libcl/) do.

kralyk commented on 2012-05-23 23:16

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

xico commented on 2012-05-08 22:43

Version 2012 is out.

Anonymous comment on 2012-02-16 11:38

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 iocgui64.sh?)

Regards

czk commented on 2011-12-22 21:30

This PKGBUILD actualy downloads intel_ocl_sdk_1.1_beta_lnx_64.rpm from http://software.intel.com/file/35820/, 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 http://software.intel.com/file/38734.

Anonymous comment on 2011-12-16 11:46

I found a bug within while using the Intel OpenCL SDK and I reported it to Intel:
http://software.intel.com/en-us/forums/showthread.php?t=101862

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

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 https://github.com/nbigaouette/oclutils/ (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

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

Sorry, version 1.5

big_gie commented on 2011-10-18 19:39

Version 1.6 came out September 26th.

kralyk commented on 2011-08-04 16:02

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

Anonymous comment on 2011-08-02 16:48

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

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

Anonymous comment on 2011-08-02 13:53

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

(typo: split off of nvidia-utils)

kralyk commented on 2011-08-01 08:30

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

I agree with yl3gdy, and libcl has already provided libOpenCL.so 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 .

monson commented on 2011-08-01 02:19

I agree with yl3gdy, and libcl has already provided libOpenCL.so so needn't install it again.

Anonymous comment on 2011-07-31 19:24

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): http://pastebin.com/qA1VWEcy

kralyk commented on 2011-07-08 13:34

Dependency bugfix. Hope it's ok.

kralyk commented on 2011-07-07 01:49

Ok, it's been updated.
Feel free to test.

(Please don't report the conflicting libOpenCL.so, 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

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

See https://github.com/nbigaouette/PKGBUILDs/tree/c75464ce4504eaf7d3841554117f7c466d85e7b0/intel-opencl-sdk 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 libOpenCL.so somewhere: I don't know how one can link with amdstream's libOpenCL.so but run using Intel's driver... Maybe libOpenCL.so 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/ld.so.conf.d/*.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

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

kralyk commented on 2011-05-13 21:53

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

kralyk commented on 2011-05-13 15:38

Okay, few tips:
→ you don't need the ld.so.conf.d entry
→ in /etc/OpenCL/vendors should be only one file "intelocl64.icd" (not directory) containing the intel so name - "libintelocl.so"
→ .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

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

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

big_gie commented on 2011-05-13 14:53

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

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

kralyk commented on 2011-05-13 14:45

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

big_gie commented on 2011-05-13 14:07

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

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

big_gie commented on 2011-05-13 13:54

New Intel's OpenCL SDK. See github ( https://github.com/nbigaouette/PKGBUILDs/tree/master/intel-opencl-sdk ) for latest version.