Package Details: intel-opencl-sdk 2020.3.494-2

Git Clone URL: https://aur.archlinux.org/intel-opencl-sdk.git (read-only, click to copy)
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: batot
Last Packager: batot
Votes: 84
Popularity: 0.000009
First Submitted: 2011-05-13 13:53 (UTC)
Last Updated: 2023-04-07 10:39 (UTC)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 .. 12 Next › Last »

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

This should use bsdtar to extract the rpm files; all rpmextract.sh 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 (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 (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/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 (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: 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)

vojtechkral 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.

« First ‹ Previous 1 2 3 4 5 6 7 8 .. 12 Next › Last »