Having OpenCL CPU device support under only one platform (NEO platform) jointly with GPU is possible?

[oscarbg]

Hi,
don't know if lame question.. but this is what we get on Windows Neo drivers after all.. right now Linux Neo OpenCL driver provides 1 platform with one GPU device, no CPU device..
seems Intel SRB 5.0 package provided both 2 devices: CPU and GPU under 1 platform..
(The intel-opencl-r5.0 (SRB5.0) Linux driver package enables OpenCL 1.2 or 2.0 on the GPU/CPU for the following Intel® processors:)
don't remember about beignet provides, but maybe similar to Neo only GPU device..
do you plan on providing (OpenCL) CPU device under NEO OpenCL platform either by reusing close source driver in Intel SRB 5.0 package or also by open sourcing Intel OpenCL CPU driver..
so briefly right now is there any solution to have both devices CPU+GPU under 1 platform?
may try to hack with SRB 5.0 OpenCL.so loader as seems the gpu driver from SRB package is named similarly to Neo igdrcl or something like that..

any way Intel open sourcing also OpenCL CPU part will be awesome.. for example for providing OpenCL 2.1 with SPIR-V CPU support to MacOS which is stalled at OpenCL 1.2.. of course if made open source doesn't need Intel or Apple approval support could be added by community and will be just a hacky way..
this is similar to how Intel OpenSWR project merged into Mesa can be compiled in MacOS providing a fast OpenGL CPU driver even using latest AVX extensions..
we will be a not obtain a Macos OpenCL.framework but a dynamic library which "homebrew" Mac apps wanting OpenCL 2.1 or SPIR-V support could link into it.. as far as they need only CPU support..
of course don't know if right place to ask for it..
feel free to point me right forum to ask if needed..
and perhaps should open a separate issue asking for it..

thanks..

[PiotrRozenfeld]

• There is currently no plan to opensource OpenCL CPU driver. Closed source remains available for Linux.
• Exposing multiple devices (CPU/GPU) under a single Intel platform requires presence of libIntelOpenCL.so - opensourcing of this library is being considered.

[oscarbg]

@PiotrRozenfeld thanks for informative reply..
regarding point #2:
yesterday I did some experiments and sad to say as far as I could learn from that experiments open sourcing libIntelOpenCL.so may even not be needed..
let me answer why:
TLDR:so briefly the problem is right now, not in libIntelOpenCL.so which is able to load Neo GPU driver correctly seems, but that OpenCL CPU closed source driver has libclang_compiler.so file pointing to libcommon_clang.so file which is also present in Neo driver, so that when I copy NEO files into a working SRB5 folder overwritting all existing files, that file is overwritten , compromising CPU driver..
(of course both CPU and GPU OpenCL portions SRB5 unified package use the same libcommon_clang.so file).. even after some hacks described in detail below to solve that problem some crash occurs which can be solved (in the sense of clinfo running completely) by renaming/deleting a file of CPU package.. scary enough..

IMHO from findings the proposed solution should be Intel to provide regularly some prebuilt binary package using CPU close source driver and precompiled NEO driver where libcommon_clang.so from Neo and CPU packages is the same dependency and the crashes that occur in CPU closed driver for whatever reason is debugged and fixed..

details below:

I extracted SRB 5.0 package and the main 3 main tar.gz files for Ubuntu (the CPU , the dev and the main with GPU support) into three different folders NOT int /opt/intel/opencl.. from that pointing /etc/OpenCL/vendors/sample.icd and having deleted the NEO .icd from vendors folder it forced to use libIntelOpenCL.so from SRB 5 but having NEO driver on /opt/intel/opencl and doing some LD_LIBRARY_PATH=/opt/intel/opencl/lib i.e. to my Intel NEO compiled driver, libIntelOpenCL.so was able to use it correctly (clinfo showed NEO device)..
that's because old closed source and NEO driver hasn't changed name share same name :igdrcl..
so libIntelOpenCL.so is able to use NEO driver correctly..
anyway wanted to see if possible to have a CPU & Neo GPU under same platform so another experiment I did is those..
delete all files..
start fresh but this time extract main SRB GPU tar.gz to a folder then copy over that folder NEO files overwriting all files (i.e. all NEO filenames: they are 4 or 5, were existing in old package) and then finally extract CPU package in same folder..
with all that done (previously had done all this manually (i.e. mixing CPU+main GPU SRB packages to see SRB5 was working correctly and could see with clinfo 1 platform with the cloused source CPU and GPU devices)..
in that way really (fixing the icd file to point to this libIntelOpenCL.so folder location and with similar LD_LIBRARY_PATH trick ) clinfo showed one platform and 2 devices first NEO working correctly and then mid CPU printing information an expection/crash ocurred.. investigating it shold be because some overwritten file I saw libclang_compiler.so from CPU package using libcommand_clang.so which I had overwritten from Neo package and clearly they are different files (perhaps even different clang versions)..
Ok so I corrected this bug by hex editor changing libclang_compiler.so to change libcommand_clang.so dependence to say libcommand_clani.so as by hex editing to work shouldn't change file sizes, and so extract original (from SRB5 package) libcommon_clang.so as libcommon_clani.so and copied to that SRB+NEO "mixed" folder having now libclang_compiler.so from CPU package modified and libcommand_clang.so from NEO package and a libcommand_clani.so from original SRB package.. still clinfo crashed at same point.. so did an strace saw loading a library of CPU package crashed clinfo so changed name of it and finally clinfo run with 1 platform and the closed source CPU package and NEO GPU driver.. anyway some CPU clinfo filed it's isn't valid doing a diff vs original CPU info from SRB5 correctly package..

[PiotrRozenfeld]

Thank you for additional debug of the problem. Your observations and conclusions seem to be valid.

Renaming libcommon_clang.so to avoid dependency conflict (to libopencl_clang.so to match repository name?) seems to be a reasonable short-term solution. We'll drive it with our colleagues maintaining opencl-clang repository.

[MichaEiler]

I just wanted to join in and mention how amazing an OpenSource Implementation for x86-64 CPUs would be! It would allow us to easily ship an additional OpenCL implementation with our application as a fallback for scenarios where the end user is using outdated/buggy graphics drivers. Currently we are planning to look into pocl. Unfortunately it seems to be significantly slower than the Intel implementation shipped with the current OpenCL CPU Runtime.