[Pkg-opencl-devel] Fwd: opencl-icd selection

[Giuseppe Bilotta]

[stupid me, sent the wrong reply button]

On Tue, Nov 18, 2014 at 2:59 PM, Rebecca N. Palmer
<rebecca_palmer at zoho.com> wrote:
> It wasn't my intention to do that, but to use a different order on systems
> where amd-opencl-icd has both a GPU and a CPU, to systems where it only has
> a CPU.  Similarly, the presence of a Phi (if we can easily identify that)
> could move intel-sdk up the list:

> {intel-sdk(Phi+CPU),nvidia}, amd(GPU+CPU), mesa, beignet, {amd(CPU
> only),intel-sdk(CPU only)}, pocl

I see, it would be used as a tie-breaker after the sort-by-device-type.

> There's no obvious right answer for the pairs in {}, so just pick an
> arbitrary order.  (intel-sdk doesn't support GPUs on Linux, only beignet
> does, https://software.intel.com/en-us/intel-opencl/details )

Ok, I've finally found some page with an OpenCL info output from a
Xeon Phi and it would seem that it's exposed as an ACCELERATOR. I'd be
prone to put INTEL before NV (when there's a Phi) on the assumption
that one would rather use the Phi than a GPU, but do applications
actually look for the ACCELERATOR type? If they don't, they might
think that the preferred platform has no devices (e.g. if they just
query the first platform for GPUs), so NV before INTEL could be
preferred.

Actually, what should we do for ACCELERATORS vs GPUs in the general
ordering? ACC > GPU > CPU or GPU > ACC > CPU or GPU | ACC (ex aequo) >
CPU ?

>> (BTW is there any intention to package the Inte
>> proprietary SDK in non-free?)
>
> It can't be because Intel prohibit redistribution.

Oh, I thought they had finally fixed that thing. Maybe some
intel-opencl-installer that grabs the upstream package, applies the
fixes from https://github.com/malcolmroberts/opencl-intel-deb-patches
and creates an installable package instead?

--
Giuseppe "Oblomov" Bilotta


-- 
Giuseppe "Oblomov" Bilotta