Re: [gentoo-dev] RFC: Rethinking virtual/opencl and eselect-opencl
On 2020-04-06 06:27, Michał Górny wrote: > While at it, is there any chance to rewrite eselect-opencl so that it > stops writing into /usr and uses environment approach like eselect- > opengl does? I think I'd rather just nuke eselect-opencl altogether and force the use of an ICD loader for all implementations. Looks like it will be easier than Matt and I thought too, touch wood: - as previously mentioned, most of the runtimes currently in the tree actually REQUIRE using an ICD loader. Of the remaining two, I know for a fact at least the latest version of intel-ocl-sdk works fine via a loader so the only one that remains to be verified is x11-drivers/nvidia-drivers[uvm]; - likewise, I have confirmed that with the possible exception of x11-drivers/nvidia-drivers[uvm], none of the presently available runtimes install their own header files that would have to be symlinked into place by eselect-opencl. -- MS signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Rethinking virtual/opencl and eselect-opencl
On Sun, 2020-04-05 at 22:13 +0100, Marek Szuba wrote: > On 2020-04-02 15:31, Marek Szuba wrote: > > > 3. Test if downstream applications are happy with the new unified OpenCL > > headers required by the Khronos Group ICD loader and if they are, add > > dev-libs/opencl-icd-loader to virtual/opencl as an alternative to ocl-icd; > > Quick update on this: today I have attempted to rebuild and test various > OpenCL-dependent packages using the unified headers and > dev-libs/opencl-icd-loader. The good news is, they have all been > perfectly happy with them. The bad news is, I actually had to manually > symlink all contents > /usr/lib/OpenCL/vendors/opencl-icd-loader/include/CL/ into > /usr/include/CL/ for this to work because eselect-opencl contains a > hard-coded list of expected vendor header files. > > In other words, it will be necessary to either teach eselect-opencl how > to handle the unified headers or make it possible for it to let the > contents of /usr/include/CL be. Personally I am leaning towards the > latter - it doesn't even handle legacy headers that well (it installs > several versions into /usr/lib/OpenCL/global but in the end offers no > way of switching between them), and in any case even its description > suggests its job is to switch between implementations rather than handle > global headers. While at it, is there any chance to rewrite eselect-opencl so that it stops writing into /usr and uses environment approach like eselect- opengl does? -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: Rethinking virtual/opencl and eselect-opencl
On 2020-04-02 15:31, Marek Szuba wrote: > 3. Test if downstream applications are happy with the new unified OpenCL > headers required by the Khronos Group ICD loader and if they are, add > dev-libs/opencl-icd-loader to virtual/opencl as an alternative to ocl-icd; Quick update on this: today I have attempted to rebuild and test various OpenCL-dependent packages using the unified headers and dev-libs/opencl-icd-loader. The good news is, they have all been perfectly happy with them. The bad news is, I actually had to manually symlink all contents /usr/lib/OpenCL/vendors/opencl-icd-loader/include/CL/ into /usr/include/CL/ for this to work because eselect-opencl contains a hard-coded list of expected vendor header files. In other words, it will be necessary to either teach eselect-opencl how to handle the unified headers or make it possible for it to let the contents of /usr/include/CL be. Personally I am leaning towards the latter - it doesn't even handle legacy headers that well (it installs several versions into /usr/lib/OpenCL/global but in the end offers no way of switching between them), and in any case even its description suggests its job is to switch between implementations rather than handle global headers. -- MS signature.asc Description: OpenPGP digital signature
