[MacOS] directory copy of OpenCL fails #258
Comments
|
Hi @jeffhammond, As I can see here, It is expected that this function will define several variables like:
If something wasn't found, then script tries to download and build corresponding components. From your logs it looks like I think you can try to pass Note, that copy command expects Line 58 in f0491f0 |
|
Unfortunately, the "find OpenCL" feature in CMake does not respect those options and insists on finding Apple OpenCL rather than failing when told to explicitly look in an invalid director, as CMake invocation from clean directoryExcerpt from CMake output |
|
It actually works on my Linux machine, but looking at sources of FindOpenCL module it probably shouldn't. What else you can try:
I also recommend to find I think that's all that I can suggest right now |
|
That sort of works, but the directory copy incorrectly assumes that Apple OpenCL headers are in ...even though CMake rightly detects that they are not... The fact that Apple alone doesn't put their OpenCL headers in Full Output |
|
@jeffhammond just comment out find_package in CMakeLists.txt. Both ICD and Headers will be downloaded from Khronos repo. A bit hacky, but seems to be working for me. Please note, that ICD is not your biggest problem.
|
|
Possibly not too interesting or helpful, but it may be interesting to someone. However, you could in theory target POCL with 2 step compile and some tinkering with the Xilinx implementation variation as it's SPIR-df (and by extension other SPIR devices I imagine). I did this ages ago before adding our own driver in, but it won't work out of the box anymore without proper usage of some LLVM passes on the kernel and the right defines passed to the device compilation, but it wouldn't be too hard I think and I'd be happy to help out if someone wants to give it a try... The main caveat with that is, you're stuck with our implementation! And we live downstream with a varied amount of delay so it doesn't progress anywhere near as fast. And we also haven't replaced a lot of the SPIRV builtins with SPIR builtins yet (in some cases it's not as easy as dropping some SPIR builtins in place, notably I think sub-groups). I think @keryell intends to eventually add support directly into the compiler via the driver for POCL/non-Xilinx SPIR devices, but that won't happen for a while I think. It's a little low down on the priority list for us at the moment.. I think alternatively with two step compilation you can quite easily get some SPIR-df kernels for POCL consumption off the ground if you're willing to stick some SPIR builtins (as long as they're global scope, the mangling should work out fine..) in place of the SIMT SPIRV builtins and hack up the runtime in a few places. |
|
@alexbatashev I really only want the compiler to work on the CPU, so I don't see why I need Apple OpenCL. Frankly, I shouldn't need a runtime or SPIR-V for the host device. At some point, we need to seriously think about portability on the CPU side to all operating systems, which means implementing the host and cpu devices with a portable runtime with minimal dependencies. I know TBB serves this purpose inside OpenCL, but it should be used directly to avoid being blocked by the inadequate OpenCL ecosystem. |
|
And to be clear, I wouldn't be in this position if triSYCL was feature-complete, but it's not and that doesn't appear to be a goal (no progress on triSYCL/triSYCL#66 in nearly two years). |
|
@jeffhammond ok, I see your point. AFAIK, host device is heavy WIP right now. But it will be implemented eventually as it is required by spec. I see 3 major blockers for SYCL on macOS:
Am I right that you don't cate about performance on macOS? If you only intend to use your macOS environment for development/debugging, and run actual workload on linux/windows, that should be relatively easy. SYCL is currently unstable, but it won't last forever. If you want to do some heavy computation on your Mac, I'm going to disappoint you. You won't get much performance. In fact, you may get significant performance regressions. |
|
@alexbatashev the CPU support should be quite simple compared to anything else, if you make the assumption that you do not support barriers and write everything in the runtime in plain modern C++ without any specific compiler support. I have updated the documentation of triSYCL in triSYCL/triSYCL#252 explaining it. Actually it was implemented by @jeffamstutz from Intel, so you know who can do the work! ;-) |
|
Finally, I could build SYCL compiler on macOS. The majority of problems lies inside RT. There's quite plenty of work to make it portable. Anyway, in spite of tons of warnings I was able to build it. I failed to build tests, but I haven't analysed the problem yet.
Set of hacks: |
|
Thanks! This is great. I will see if I can figure out some of the errors.
|
|
BTW, this is sample of errors I see: They are the same for every single test. Most likely will be resolved by env variables or something like this. |
|
Ah that’s pretty common with Clang on Apple it it’s not configured to know where Apple headers are.
|
|
@jeffhammond Is this to motivate people to use ObjectiveC(++)/Swift by showing C++ is broken? :-/ |
|
@keryell on Linux app typically takes root in may different places (/usr/lib, /etc, /opt, ...). On macOS application is a sort of self-contained zip archive. So, Xcode (default macOS IDE) brings its headers under |
|
@alexbatashev yes you are right, there are some advantages too. But you might end up with a lot of duplication too... We need a good package manager. :-) |
romanovvlad
added
the
help wanted
|
@jeffhammond Could you please clarify if the problem has been resolved? |
|
I no longer have a professional reason to compile DPC++ on MacOS so I haven't tried in at least a year. Feel free to close if you want. |
This patch contains minimal changes to make compiler toolchain builds succeed on macOS: - Add stubs for platform-dependent functions - Disable level zero plugin for macOS exclusively - Fix platform-dependent library names - Remove get_device_count_by_type tool (which is unused, and rather than fixing it, removal is much simpler) - Add minimal CI in post-commit to prevent build breakages in future The above changes are far from fully working SYCL on Darwin targets, this patch only fixes toolchain builds, and does not attempt to make the toolchain itself functional. Fixes #258 Fixes #982
I understand that MacOS is not a priority and that supporting Apple OpenCL is impossible due to lack of SPIR-V. However, it seems that the current testing for OpenCL support is inadequate, as it doesn't determine if the OpenCL CMake finds is sufficient.
I'd like to use POCL for OpenCL CPU support on MacOS, which shouldn't be any different than POCL on Linux. What are the CMake variables to tell the build system to look for POCL instead? I've made many attempts at this but nothing documented on the internet is working.
Steps to reproduce
The text was updated successfully, but these errors were encountered: