Marking for review as I think it's nearly ready and it would be good to have feedback.
Also, I'm not sure how to fix the opengl.extraPackages issue.

Now updated to latest release versions targeting LLVM 8.

Tested on unstable (b5f5c97), but something seems to have changed with the openGL rpath handling; before, I thought I had /run/opengl-driver in LD_LIBRARY_PATH, but now my LD_LIBRARY_PATH is empty.

How do we sort this out? Any OpenCL program which loads Neo will need to access the libraries from intel-gmmlib and intel-graphics-compiler. Do we need to use addOpenGLRunpath on every OpenCL client executable? I hope not. Ping @abbradar @ambrop72

I would love to get some traction on this.
@volth @dtzWill @Ericson2314 @worldofpeace
Would anyone volunteer to review or take ownership of this PR?

@gloaming Yes we got rid of LD_LIBRARY_PATH. If an application needs to load vendor-specific libraries from there (as opposed to using standard APIs like OpenGL, Vulkan, OpenCL), it needs to use addOpenGLRunpath. Any application that dlopens some library needs suitable RUNPATH (or a wrapper setting LD_LIBRARY_PATH), and these driver libraries should not be special.

@gloaming Just to be clear, standard OpenCL programs that don't themselves depend on Intel libraries should be able to work with any OpenCL runtime including this one. If this is not the case, something is wrong and needs to be addressed. I'm not familiar with the details but I'll try to give it a test.

@ambrop72 Thanks for explaining! Yes, the problem is that the intel runtime itself (libigdrcl.so) dlopens the other Intel libraries. I did try using addOpenGLRunpath $out/lib/* before.. But I didn't realise there was another folder inside lib! addOpenGLRunpath $out/lib/intel-opencl/libigdrcl.so did the job.

However, I think it would be better to add just the Intel libraries to libigdrcl.so's RUNPATH rather than use addOpenGLRunpath. It's cleaner, and avoids the impurity of /run/opengl-driver. Do you agree?

However, I think it would be better to add just the Intel libraries to libigdrcl.so's RUNPATH rather than use addOpenGLRunpath. It's cleaner, and avoids the impurity of /run/opengl-driver. Do you agree?

Yes. We only have /run/opengl-driver in order to switch between opengl driver without recompiling. Dependencies within a driver can be resolved straight away without this hack.

@ambrop72 Thanks for explaining! Yes, the problem is that the intel runtime itself (libigdrcl.so) dlopens the other Intel libraries. I did try using addOpenGLRunpath $out/lib/* before.. But I didn't realise there was another folder inside lib! addOpenGLRunpath $out/lib/intel-opencl/libigdrcl.so did the job.

However, I think it would be better to add just the Intel libraries to libigdrcl.so's RUNPATH rather than use addOpenGLRunpath. It's cleaner, and avoids the impurity of /run/opengl-driver. Do you agree?

Yes, just add appropriate absolute RUNPATH to the libraries so that they find their internal dependencies. I actually ran into the same problem with the NVidia driver when I was getting rid of the LD_LIBRARY_PATH, it worked only because the internal libraries happened to be found via LD_LIBRARY_PATH.

RUNPATH fixed and tested. Looks good.

https://github.com/NixOS/nixpkgs/blob/675927dbfc9078c502884e7966b4fd55ba89ca41/pkgs/development/libraries/opencl-clang/cc-wrapper.patch#L26-L33

This is a bit of an essay. Would it be better to create an issue and replace it with a short comment and a link?

ping @Mic92 @Ericson2314

Updated to latest versions, including unstable for opencl-clang so as not to require the patch-fixing mess.

I'm really excited to see this in nixpkgs! Is there anything stopping this from getting merged?

@GrahamcOfBorg eval

Thanks!

Not sure if this is the right place to ask but i'm struggling making opencl work: while this PR successfully finds a opencl platform with opencl-info (output), it fails to do so with clinfo and any other tool depending on opencl:

$ clinfo
Number of platforms                               0

however, strace tells me that it could successfully locate the correct icd and lib:

$ strace clinfo
...
openat(AT_FDCWD, "/run/opengl-driver/etc/OpenCL/vendors/intel-neo.icd", O_RDONLY) = 4
...
openat(AT_FDCWD, "/nix/store/y6ip2sw1g2l796n7hvxr72hf6pcrp9rm-intel-compute-runtime-19.34.13959/lib/intel-opencl/libigdrcl.so", O_RDONLY|O_CLOEXEC) = 4

am i missing something trivial?
@gloaming

@mhhf Sorry for the slow response - I'm not aware of anything obvious. Do you also see openats for libigdrcl.so, libva.so etc? If this is still happening, best to open an issue rather than discuss here.

In case anyone is having the same issue, the problem was with libstdc++.so.6 not being found by clinfo and other tools. Extending the LD_LIBRARY_PATH in a shell.nix (e.g. LD_LIBRARY_PATH = "${pkgs.stdenv.cc.cc.lib}/lib64:$LD_LIBRARY_PATH";) solved that issue.