Add OpenCL SDK and clMath ports #2837
Conversation
|
|
|
I just wanted to invite @BenjaminCoquelle into the conversation, contributor to most clMath libraries, plus I believe he packaged OCL_SDK_Light.zip for Windows. I think he would be interested in vcpkg.exe install opencl clfft[fftw3] clblas clsparse |
|
The ICD (OpenCL.dll) should only come with the driver. |
|
Heeding Benjamins advice, I modified the script to not deploy the DLLs, only the LIBs. There is a post-build check that's failing, but I don't understand it. Looking inside the build logs, the library was indeed built using separate flags, but the .lib files are identical to the last bit. ??? Release[2/6] C:\Kellekek\MICROS Debug[2/6] C:\Kellekek\MICROS Because the OpenCL.dll is a system DLL anyway and there is no reason to build a Debug version of it, is there a way to disable this check and omit debug builds all together and only deploy release builds ? |
|
@ras0219-msft Could you let me know how to omit Debug builds if I want to conform to having only the drivers shipping a Release DLL? The docs did not help, neither searching the previous issues. |
|
Thanks for making this PR! First, the error message is actually catching a misplacement of lib files:
These should be in We don't currently have an easy way to reliably opt-out from building Debug, but could you try the above changes first and see if that works? |
|
Thanks for the input. It does work indeed. I already tested the SDK and it seems to work now. I proceeded to tweaking clFFT and it builds fine, even installs and passes post-build tests, but consumers cannot detect it properly. First, the Package Config files are not found. It argues about If I register the installed package into my user package registry, it is found alright, but the headers are not found when building. include(${CMAKE_CURRENT_LIST_DIR}/clFFTTargets.cmake)
get_filename_component(CLFFT_INCLUDE_DIRS ${CMAKE_CURRENT_LIST_DIR}/../include ABSOLUTE)
set(CLFFT_LIBRARIES clFFT)However, How should I go about fixing a generated package config file that is generated in a manner not to be relocated, moreover have it's layout changed? Or am I doing something totally wrong? Should you want to give it a try, clone my working tree and try building a simple sample found here. |
|
@ras0219-msft Thanks for the help thus far. Getting clFFT to build was tougher than I had anticipated (infact, this entire process is a lot harder than I had anticipated). Once, when everything was building, It failed to link the sample clFFT_test application, because of MT/MD mismatch. (By default, CMake uses MD, and the built-in x64-windows-static also links the CRT statically. Because I did not want to set MT in ALL my downstream projects, I went ahead and started using x64-windows instead.) Now my problem is (for some reason), is that OpenCL detection via the built-in FindOpenCL.cmake is half baked. This is the config output when building the clFFT runtime library: Notice that message(STATUS "OpenCL_INCLUDE_DIRS: ${OpenCL_INCLUDE_DIRS}")returns find_library(OpenCL_LIBRARY
NAMES OpenCL
PATHS
ENV "PROGRAMFILES(X86)"
ENV AMDAPPSDKROOT
ENV INTELOCLSDKROOT
ENV CUDA_PATH
ENV NVSDKCOMPUTE_ROOT
ENV ATISTREAMSDKROOT
PATH_SUFFIXES
"AMD APP/lib/x86_64"
lib/x86_64
lib/x64
OpenCL/common/lib/x64)Is there a way to manipulate the tool-chain file to force defining the key variables, |
|
Sorry it's so tough!
We definitely do[1] have that capability, and already use it for other libraries. Note, however, that environment variables will not be passed through to the actual build (to ensure it's reproducible on other machines). You can see what the build environment looks like by running
Yep, this is a very common issue! We have a helper which does all the common fixups needed called [1] https://github.com/Microsoft/vcpkg/blob/4642191a099ddd578a46ecbb2c08899233e9e754/scripts/buildsystems/vcpkg.cmake#L185-L253 |
|
Apologies for being such a slow learner, but there must be a fundamental misunderstanding between me and Vcpkg. How come that if a package installs inside Here's my problem: find_package(OpenCL) works as long as What am I doing wrong? (After all these noobish questions, you'll might just have another package maintainer producing all sorts of HPC goodies.) |
|
So it turns out that clfft was secretly to blame :) They included their own FindOpenCL.cmake[1] file which was shadowing the built-in copy. Their version sets Once I reverted the variable names back to the uppercase forms, everything just worked! I also converted your file-based replacements into a patch file -- it's problematic for us to check in entire source files, plus they're much larger! You'll need to delete your Since everything appears working to me, I've gone ahead and merged it. If you encounter any more issues, please let us know and/or make a PR! Thanks so much for this effort, OpenCL is really popular so it's great to have it in Vcpkg! [1] https://github.com/clMathLibraries/clFFT/blob/v2.12.2/src/FindOpenCL.cmake |
|
There were multiple things at fault. Because I started running low on time with the project I started this development for, I started putting my environment separate from Vcpkg. I noticed just before leaving work (you beat me to reporting it), that I couldn't guide find_package(OpenCL) with the mixed case variables, because of the outdated (pre-CMake 3.0?) style scripts. Second, this only became apparent when I did a build outside VS Code, which I primarily use for development. The compiler detection feature (Kits)[1] of CMake Tools and the toolchain file was disregarded. I found a workaround since, but it still requites a bit of tweaking. Based on your work, I'll add the very similar clBLAS, clRNG and hopefully the clSPARSE libs too. [1] |
|
If only |
I would like to invite people to help me with constructive criticism and guidance in creating these new, highly inter-related ports. While the OpenCL SDK in itself could stand, I do want to get all of the mentioned in the matching issue as well.
I started the portfile, but there are some errors I don't know how to go about fixing, partly because I donnodawey.
General
I can't quite grasp how it would be optimal to package all of the above SW. The minimal OpenCL SDK consists of the C API headers and the ICD. The prior is included in source files, the latter is linked against. On Linux, these are usually separate packages. On Windows, every SDK ships both as well (AMD APP SDK, Intel OpenCL SDK, Nvidia CUDA SDK), but all the GPU drivers also ship the ICD (which will install under
C:\Windows\system32\OpenCL.dll), this is what all applications will pick up if there's no alternative installed beside the exe. The DLLs in the SDKs are only to make the linker happy.So if you have something to hook a display on to, Windows Update will pull alongside your drivers an OpenCL ICD and install it in a default location. This ICD at best is the very same that is found in the Khronos repo, but is most likely outdated compared to the one we're trying to package here.
OpenCL ICD/SDK
For those that don't know, this library is responsible for dynamically loading the vendor implementations of OpenCL. It is the GLVND of OpenCL, but it's been there since day one. This library canonically is a dynamic library (I've never encountered any indication of it having to be that way, but) nobody expects it to be linked statically. Therefor I would like to forbid it being built as a static lib. This part is written as it should be I guess.
Currently there are post-build validation scripts that argue about mismatching number of debug and release binaries. The reason I don't know how to fix this, is because canonically one never meets debug builds of the OpenCL ICD (aka. OpenCL.dll), as it's usually obtained with drivers. Although in some cases it might be nice to be able to step through the ICD. This would be the case of faulty driver installations when a call to
clGetPlatformIDs()results in the undocumented-1000error code, which corresponds to: something went wrong while loading some vendor implementation.Few questions:
openclmeta-package?FindOpenCL.cmakedoesn't even look for it. What do you think should be the best way to fix this "problem"? Shall I patch CMakesFindOpenCL.cmaketo also include anOpenCL::CLHPPimported target and try using that here as well?clMath
clMath is the collective name for clFFT, clBLAS, clRNG and clSPARSE. These are definitely big enough to be separate packages, but are meta-packages still a thing? There are traces of a time when Boost was a meta-package that referred to other packages.
Once I gain enough experience with the OpenCL SDK, I'll incorporate the clMath stuff as well into the PR.