Bug 396033 – freeocl-0.1.0 (new package)

• Product: Gentoo Linux
• Status: RESOLVED WONTFIX

[Description emil karlson 2011-12-26 03:32:15 UTC]

Freeocl includes an icd wrapper that has modest dependencies and is an alternative to eselect-opencl https://bugs.gentoo.org/show_bug.cgi?id=372847 .

ICD is a interface for multiple opencl implementations to coexist (spec
http://www.khronos.org/registry/cl/extensions/khr/cl_khr_icd.txt )

The solution would be to make other implementations depend on this (or an other icd wrapper) and not install OpenCL headers or libs, only icd-files and vendor specific libs. This way that freeocl could load those libraries and export as different platforms for it's libOpenCL.so without any eselecting.

Reproducible: Always

[Comment 1 emil karlson 2011-12-26 03:55:47 UTC]

Created attachment 296939 [details]
freeocl-PV.ebuild

Ebuild I tested the icd wrapper with ati-drivers and some of my own code.

TODO
verify header sanity (beyond wine configure I tested).

Deal with multilib:
Should the vendor specific libs use the same name for the icd to work or should we add icd for both.
The ebuild needs multilib support.

OpenCL-1.2
This is upstream work, but pretty trivial, since it's only wrapper.

(homepage btw http://code.google.com/p/freeocl/ )

[Comment 2 emil karlson 2011-12-26 04:08:03 UTC]

Created attachment 296941 [details]
freeocl-0.1.0-clSetCommandQueueProperty.patch

patch for the ebuild against latest svn snapshot (sent to upstream).

btw. wine[opencl] compiled fine against freeocl headers and ati-drivers-11.12[opencl] and some ugly symlinks.

[Comment 3 Matthew Smith 2021-12-19 11:30:46 UTC]

Upstream seems dead (migrated to GitHub from Google Code, last commit 4 years ago, issues ignored since then too).

Also not sure of the utility of it in 2021, no other distro seems to package it still.