You can subscribe to this list here.
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(25) |
Nov
(11) |
Dec
(36) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2012 |
Jan
(30) |
Feb
(4) |
Mar
(4) |
Apr
(7) |
May
(5) |
Jun
(31) |
Jul
(6) |
Aug
(19) |
Sep
(38) |
Oct
(30) |
Nov
(22) |
Dec
(19) |
2013 |
Jan
(55) |
Feb
(39) |
Mar
(77) |
Apr
(10) |
May
(83) |
Jun
(52) |
Jul
(86) |
Aug
(61) |
Sep
(29) |
Oct
(9) |
Nov
(38) |
Dec
(22) |
2014 |
Jan
(14) |
Feb
(29) |
Mar
(4) |
Apr
(19) |
May
(3) |
Jun
(27) |
Jul
(6) |
Aug
(5) |
Sep
(3) |
Oct
(48) |
Nov
|
Dec
(5) |
2015 |
Jan
(8) |
Feb
(2) |
Mar
(8) |
Apr
(16) |
May
|
Jun
|
Jul
(2) |
Aug
(1) |
Sep
(2) |
Oct
(13) |
Nov
(5) |
Dec
(2) |
2016 |
Jan
(26) |
Feb
(6) |
Mar
(8) |
Apr
(8) |
May
(2) |
Jun
|
Jul
|
Aug
(11) |
Sep
(3) |
Oct
(5) |
Nov
(14) |
Dec
(2) |
2017 |
Jan
(16) |
Feb
(4) |
Mar
(11) |
Apr
(4) |
May
(5) |
Jun
(5) |
Jul
(3) |
Aug
|
Sep
(6) |
Oct
|
Nov
(10) |
Dec
(6) |
2018 |
Jan
|
Feb
(21) |
Mar
(11) |
Apr
(3) |
May
(2) |
Jun
(8) |
Jul
|
Aug
(13) |
Sep
(6) |
Oct
(2) |
Nov
|
Dec
(11) |
2019 |
Jan
|
Feb
(5) |
Mar
(10) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(10) |
Oct
(4) |
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
(1) |
Apr
(4) |
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
(4) |
2021 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
|
2022 |
Jan
|
Feb
|
Mar
(4) |
Apr
|
May
(11) |
Jun
(1) |
Jul
(3) |
Aug
|
Sep
(1) |
Oct
|
Nov
(2) |
Dec
(1) |
2023 |
Jan
(4) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
From: FreeBSD U. <fr...@wa...> - 2023-12-17 11:47:37
|
Hello, tried to compile POCL-5.0-RC1 on top of the existing FreeBSD port lang/pocl (minor adaptions). On recent FreeBSD CURRENT (FreeBSD 15.0-CURRENT #11 main-n266974-6f3e9bac4d46: Sat Dec 16 17:40:52 CET 2023 amd64), with system compile llvm-17 (FreeBSD clang version 17.0.6 (https://github.com/llvm/llvm-project.git llvmorg-17.0.6-0-g6009708b4367)). The compilation bails out on the error: [...] [...] FAILED: lib/CL/devices/CMakeFiles/pocl-devices.dir/common.c.o /usr/bin/cc -DCL_HPP_TARGET_OPENCL_VERSION=300 -DCL_TARGET_OPENCL_VERSION=300 -DCL_USE_DEPRECATED_OPENCL_1_0_APIS -DCL_USE_DEPRECATED_OPENCL_1_1_APIS -DCL_USE_DEPRECATED_OPENCL_1_2_APIS -DCL_USE_DEPRECATED_OPENCL_2_0_APIS -DCL_USE_DEPRECATED_OPENCL_2_1_APIS -DCL_USE_DEPRECATED_OPENCL_2_2_APIS -I/usr/ports/lang/pocl/work/.build -I/usr/ports/lang/pocl/work/pocl-5.0-RC1/include -I/usr/ports/lang/pocl/work/pocl-5.0-RC1/include/hpp -I/usr/ports/lang/pocl/work/pocl-5.0-RC1/lib/CL/devices -I/usr/ports/lang/pocl/work/pocl-5.0-RC1/lib/CL/. -O2 -pipe -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -O2 -pipe -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -DNDEBUG -fPIC -Werror=implicit-function-declaration -Werror=incompatible-pointer-types -Wno-ignored-attributes -fvisibility=hidden -MD -MT lib/CL/devices/CMakeFiles/pocl-devices.dir/common.c.o -MF lib/CL/devices/CMakeFiles/pocl-devices.dir/common.c.o.d -o lib/CL/devices/CMakeFiles/pocl-devices.dir/common.c.o -c /usr/ports/lang/pocl/work/pocl-5.0-RC1/lib/CL/devices/common.c /usr/ports/lang/pocl/work/pocl-5.0-RC1/lib/CL/devices/common.c:1682:9: error: initializing 'char *' with an expression of type 'const char *' discards qualifiers [-Werror,-Wincompatible-pointer-types-discards-qualifiers] 1682 | char* kernellib_variant = pocl_get_distro_kernellib_variant (); | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ It seems (to me, non-developer) that the error occurs due to a missing const declaration in common.c, simply following the compiler's error message. The patch sketched below solves the problem for me on CURRENT. --- lib/CL/devices/common.c.orig 2023-12-15 17:48:18 UTC +++ lib/CL/devices/common.c @@ -1679,7 +1679,7 @@ pocl_init_default_device_infos (cl_device_id dev) strcat(kernellib, "-"); #ifdef KERNELLIB_HOST_DISTRO_VARIANTS - char* kernellib_variant = pocl_get_distro_kernellib_variant (); + const char* kernellib_variant = pocl_get_distro_kernellib_variant (); dev->llvm_cpu = pocl_get_distro_cpu_name (kernellib_variant); strcat(kernellib, kernellib_variant); if (!kernellib_variant) Thanks oh -- O. Hartmann |
From: Michal B. <int...@ru...> - 2023-06-22 10:05:04
|
Hello all, PoCL 4.0 has been released today. It comes with many new features and bugfixes. You can get it here: https://github.com/pocl/pocl/releases/tag/v4.0 You can read the full release notes here: https://github.com/pocl/pocl/blob/release_4_0/doc/notes_4_0.rst Regards, -- mb |
From: Michal B. <int...@ru...> - 2023-06-05 10:49:47
|
Hello, LLVM 16.0 has been out for a while, so it's time for a new PoCL release. There are quite a few new features and bugfixes, for the full list see CHANGES (documentation is still WIP). Please download and test it: https://github.com/pocl/pocl/releases/tag/v4.0-RC1 Please log your results into the wikipage: https://github.com/pocl/pocl/wiki/Release-testing-of-pocl-4.0 Regards, -- mb |
From: Zhang X. <xi...@pe...> - 2023-03-09 08:24:27
|
Hi, I am Xianyi from PerfXLab. Our team have a fork repo for supporting RISC-V. https://github.com/PerfXLab/pocl and, we created a PR about RISC-V https://github.com/pocl/pocl/pull/1109 Regards, Xianyi |
From: Andreas K. <li...@in...> - 2023-01-17 20:39:40
|
Pekka Jääskeläinen (TAU) <pek...@tu...> writes: > Hi Noah, > > I'm not aware of anyone implementing this on pocl-cuda. It might be not a lot of work to do so. Here's the cl_mem's internal pointer array: https://github.com/pocl/pocl/blob/master/lib/CL/pocl_cl.h#L1409 > > A clean implementation would be to define an OpenCL extension which > allows one to query the device pointer. Strictly put the device > pointer might be there or might not since lazy/just-in-time buffer > allocation is allowed in OpenCL, but it should work for pocl-cuda, I > think. Matthias Diener's work towards shared virtual memory with pocl-cuda may also be of interest. https://github.com/pocl/pocl/pull/1067 Note that that PR needs some work, as I point out on Github. Andreas -- |
From: Pekka J. (T. <pek...@tu...> - 2023-01-17 17:00:55
|
Hi Noah, I'm not aware of anyone implementing this on pocl-cuda. It might be not a lot of work to do so. Here's the cl_mem's internal pointer array: https://github.com/pocl/pocl/blob/master/lib/CL/pocl_cl.h#L1409 A clean implementation would be to define an OpenCL extension which allows one to query the device pointer. Strictly put the device pointer might be there or might not since lazy/just-in-time buffer allocation is allowed in OpenCL, but it should work for pocl-cuda, I think. BR, Pekka ________________________________________ From: Noah Reddell <noa...@gm...> Sent: 11 January 2023 23:58 To: Portable Computing Language development discussion Subject: [pocl-devel] device pointer for NVIDIA + MPI systems Hi All, I'm trying to find a working method, or short-term hack of a working method, to adapt my OpenCL application to run well on contemporary HPC systems with NVIDIA GPUs. (i.e. Perlmutter at NERSC) For this, I want or need to use GPU-side device pointers in the Message Passing Interface (MPI) arguments for communication between nodes on the supercomputer. As far as I can tell, OpenCL provides no mechanism to obtain the device-side memory pointer for either a cl_mem buffer object or SVM allocation. I would need this pointer to use with MPI calls. In CUDA-based prototype codes, this type of MPI use to/from GPU memory is straightforward because cudaMaloc() returns a device pointer that is accepted in MPI_xyz() calls. Has anyone tried something like this with POCL using the CUDA backend? Or is there familiarity with the implementation that would suggest how to get at this device pointer from a cl_mem object ? Cheers, -Noah |
From: Noah R. <noa...@gm...> - 2023-01-11 21:58:47
|
Hi All, I'm trying to find a working method, or short-term hack of a working method, to adapt my OpenCL application to run well on contemporary HPC systems with NVIDIA GPUs. (i.e. Perlmutter at NERSC) For this, I want or need to use GPU-side device pointers in the Message Passing Interface (MPI) arguments for communication between nodes on the supercomputer. As far as I can tell, OpenCL provides no mechanism to obtain the device-side memory pointer for either a cl_mem buffer object or SVM allocation. I would need this pointer to use with MPI calls. In CUDA-based prototype codes, this type of MPI use to/from GPU memory is straightforward because cudaMaloc() returns a device pointer that is accepted in MPI_xyz() calls. Has anyone tried something like this with POCL using the CUDA backend? Or is there familiarity with the implementation that would suggest how to get at this device pointer from a cl_mem object ? Cheers, -Noah |
From: Manan k. <mka...@gm...> - 2023-01-07 12:39:50
|
hello there i am new to pocl how i started to develop with you |
From: Jan S. (TAU) <jan...@tu...> - 2022-12-05 13:15:02
|
PoCL is a portable open source (MIT-licensed) implementation of the OpenCL standard. It likely supports the minimal v3.0 feature set (official conformance stamp not yet applied for). In addition to being an easily portable multi-device (truly heterogeneous) open-source OpenCL implementation, a major goal of the project is improving interoperability for diversity of OpenCL-capable devices by integrating them to a single centrally orchestrated platform. Another key goal is to enhance performance portability of OpenCL programs across device types utilizing runtime and compiler techniques. Upstream PoCL currently supports various CPUs, NVIDIA GPUs via libcuda, Vulkan-compatible GPUs (experimental) and ASIPs (experimental, see: http://openasip.org). It is also known to have multiple (private) adaptations in active production use. Release Highlights ------------------ * Support for Clang/LLVM 15.0 * Much improved SPIR-V support for CPU and CUDA drivers * Major rework of the custom device driver (formerly named Accel, now AlmaIF) with support for more device types implementing AlmaIF * Various improvements to the work-in-progress Vulkan driver * Basic implementation of cl_khr_command_buffer Misc. Notes ----------- * Please note that there's an official PoCL "maintenance policy" in place. This text describes the policy and how you can get your favourite project that uses OpenCL to remain regression free in the future PoCL releases: http://portablecl.org/docs/html/maintainer-policy.html * We are looking for ARM CPU and RISC-V CPU maintainers (and any other target of your interest). If you are interested in ensuring PoCL stays stable for these processor architectures in the future, please contact us. * The dedicated TTASim driver will be deprecated once the AlmaIF driver reaches feature parity with it. * Support for LLVM versions below 10 will be removed in the next release. If you rely on these versions, please let us know. Acknowledgements ---------------- Customized Parallel Computing (CPC) research group of Tampere University, Finland leads the development of PoCL on the side and for the needs of their research projects. This project has received funding from European Union's Horizon 2020 research and innovation programme under Grant Agreement No 871738 (CPSoSaware), Academy of Finland (decision #331344) and Business Finland's AISA project. The financial support is very much appreciated -- it keeps this open source project going! Links ----- Release web page: http://portablecl.org/pocl-3.1.html -- Jan |
From: Jan S. (TAU) <jan...@tu...> - 2022-11-22 17:57:28
|
Hello all, LLVM 15.0 has been out for a while so a new PoCL release is in order. There are lots of other exciting changes as well: * The Accel custom device driver has seen some major reworking and is now called AlmaIF * SPIR-V support for CPU and CUDA devices has been greatly improved * The experimental Vulkan driver is closer to being a full-fledged driver * There is a basic implementation of the provisional command buffer extension Note that the TTASim driver will be superseded by the AlmaIF driver and deprecated once the AlmaIF driver reaches feature parity with it. I’ve created RC1: https://github.com/pocl/pocl/releases/tag/v3.1-RC1 Please test and report your results here: https://github.com/pocl/pocl/wiki/Release-testing-of-pocl-3.1 or file issues on GitHub. Regards, — Jan Solanti |
From: rocky r. <roc...@gm...> - 2022-11-02 17:23:12
|
After I installed pocl, I found that the include directory was not installed in the directory specified by *'-DCMAKE_INSTALL_PREFIX='*, but was generated in the *share* directory under the directory specified by* -DCMAKE_INSTALL_PREFIX*= The directory tree is as follows: pocl ├── exe (Specify the installation directory) │ ├── bin │ ├── etc │ │ └── OpenCL │ │ └── vendors │ ├── lib64 │ │ ├── pkgconfig │ │ └── pocl │ └── share │ └── pocl │ └── include But the content of my pocl.pc file is as follows: prefix=/pocl/exe exec_prefix=/pocl/exe/bin libdir=/pocl/exe/lib64 includedir=/pocl/exe/include Name: Portable Computing Language Description: Portable Computing Language Version: 3.1-pre master-0-gcbbd8b97 Libs: -L${libdir} -lpocl Cflags: -I${includedir} This results in the command `pkg-config --libs --cflags pocl` prompting the error bash: -Ipocl/exe/include: No such file or directory And even if I manually adjust the* includedir *path of the pocl.pc file, I still get the same error message. How can I adjust this part to get the correct result? Thanks |
From: <sx...@qq...> - 2022-09-09 08:06:53
|
Hello, everyone I ran into a problem with POCL 3.0. I want to run POCL in an RTOS. After comprehensive consideration, I think cross-compilation is suitable. However, in this RTOS, there is no OCL-ICD mentioned in the file ToolchainExample.cmake. If so, what exactly should I do? |
From: Gokhan S. <gok...@gm...> - 2022-07-28 21:32:35
|
Hi everyone, I am new for pocl and opencl. I download pocl source code can build it, also checked with clinfo, everything is Ok. However, I am confused that create a new project with pocl, is there any example except ones in source code? Or please help me how to create and compile an example with gcc in C language. Also, I think it will be good to create a repo for examples. Best regards. |
From: Pekka J. <pek...@tu...> - 2022-07-15 13:01:48
|
Hi Noah, This is likely due to not having proper detection implemented for Apple. Normally we use hwloc for detecting the mem. Is it not available for you or does it report the RAM wrongly? The code is around here if you are interested in investigating and perhaps contributing a fix: https://github.com/pocl/pocl/blob/master/lib/CL/devices/topology/pocl_topology.c#L121 HTH, Pekka On 12.7.2022 20.54, Noah Reddell wrote: > Hi, > > I'm wondering why the POCL memory limits are so small relative to > my machine RAM and other OpenCL implementations. Can I increase these > device limits? > I'm running POCL 3.0 from conda-forge on an M1 Pro Mac with 64GB > RAM. Install and self-reported properties: > pocl 3.0 h422b2f1_0 conda-forge > > CL_PLATFORM_PROFILE: FULL_PROFILE > CL_PLATFORM_VERSION: OpenCL 3.0 PoCL 3.0-rc2 Apple, Release, RELOC, > LLVM 14.0.4, SLEEF, FP16, POCL_DEBUG > CL_DEVICE_NAME: pthread > CL_DEVICE_TYPE: CPU > > > POCL Reporting from clGetDeviceInfo: > (app built with -DCL_TARGET_OPENCL_VERSION=120) > > CL_DEVICE_GLOBAL_MEM_SIZE: 2,530,467,840 bytes. (~2 GB) > CL_DEVICE_MAX_MEM_ALLOC_SIZE: 1,073,741,824 bytes. (~1 GB) > > Apple's OpenCL implementation is reporting much more availability > total and per-buffer. > CL_DEVICE_GLOBAL_MEM_SIZE: 51,539,607,552 bytes. (~51 GB) > CL_DEVICE_MAX_MEM_ALLOC_SIZE: 9,663,676,416 bytes. (~9 GB) > > The observed POCL memory limits are hampering the type of simulations > I am able to run. I've seen other platforms limit to 4GB allocations > before, but not in a while. > > Warm regards, > > Noah > > > _______________________________________________ > pocl-devel mailing list > poc...@li... > https://lists.sourceforge.net/lists/listinfo/pocl-devel |
From: Noah R. <noa...@gm...> - 2022-07-12 17:54:52
|
Hi, I'm wondering why the POCL memory limits are so small relative to my machine RAM and other OpenCL implementations. Can I increase these device limits? I'm running POCL 3.0 from conda-forge on an M1 Pro Mac with 64GB RAM. Install and self-reported properties: pocl 3.0 h422b2f1_0 conda-forge CL_PLATFORM_PROFILE: FULL_PROFILE CL_PLATFORM_VERSION: OpenCL 3.0 PoCL 3.0-rc2 Apple, Release, RELOC, LLVM 14.0.4, SLEEF, FP16, POCL_DEBUG CL_DEVICE_NAME: pthread CL_DEVICE_TYPE: CPU POCL Reporting from clGetDeviceInfo: (app built with -DCL_TARGET_OPENCL_VERSION=120) CL_DEVICE_GLOBAL_MEM_SIZE: 2,530,467,840 bytes. (~2 GB) CL_DEVICE_MAX_MEM_ALLOC_SIZE: 1,073,741,824 bytes. (~1 GB) Apple's OpenCL implementation is reporting much more availability total and per-buffer. CL_DEVICE_GLOBAL_MEM_SIZE: 51,539,607,552 bytes. (~51 GB) CL_DEVICE_MAX_MEM_ALLOC_SIZE: 9,663,676,416 bytes. (~9 GB) The observed POCL memory limits are hampering the type of simulations I am able to run. I've seen other platforms limit to 4GB allocations before, but not in a while. Warm regards, Noah |
From: Pekka J. <pek...@tu...> - 2022-06-10 11:30:35
|
PoCL is a portable open source (MIT-licensed) implementation of the OpenCL standard. It likely supports the minimal v3.0 feature set (official conformance stamp not yet applied for). In addition to being an easily portable multi-device (truly heterogeneous) open-source OpenCL implementation, a major goal of this project is improving interoperability for diversity of OpenCL-capable devices by integrating them to a single centrally orchestrated platform. Another key goal is to enhance performance portability of OpenCL programs across device types utilizing runtime and compiler techniques. Upstream PoCL currently supports various CPUs, NVIDIA GPUs via libcuda and ASIPs (experimental, see: http://openasip.org). It is also known to have multiple (private) adaptations in active production use. Release Highlights ------------------ * Minimal OpenCL 3.0 feature set _should_ be now supported (official conformance stamp still to apply for). * Support for Clang/LLVM 14.0. * Improved tracing and visualization. * Support for generating specialized work-group functions and include them in the PoCL kernel program binaries. * Fixed printf for SPIR-V. * A lot of other fixes and improvements. Misc. Notes ----------- * Please note that there's an official PoCL "maintenance policy" in place. This text describes the policy and how you can get your favourite project that uses OpenCL to remain regression free in the future PoCL releases: http://portablecl.org/docs/html/maintainer-policy.html * We are still looking for ARM CPU and RISC-V CPU maintainers (and any other target of your interest). If you are interested in ensuring PoCL stays stable for these processor architectures in the future, please contact us. Acknowledgements ---------------- Customized Parallel Computing (CPC) research group of Tampere University, Finland leads the development of PoCL on the side and for the needs of their research projects. This project has received funding from European Union's Horizon 2020 research and innovation programme under Grant Agreement No 871738 (CPSoSaware), Academy of Finland (decision #331344) and Business Finland's AISA project. The financial support is very much appreciated -- it keeps this open source project going! Links ----- Release web page: http://portablecl.org/pocl-3.0.html This announcement: http://portablecl.org/downloads/ANNOUNCEMENT Change log: http://portablecl.org/downloads/CHANGES Download: http://portablecl.org/download.html -- Pekka |
From: Noah R. <noa...@gm...> - 2022-05-20 18:20:15
|
Hi Isuru, Indeed, modifying PATH by prepending /Users/noah/miniforge3/bin at runtime resolved this issue. So the late-binding link at clEnqueueNDRangeKernel() was calling the wrong ld executable. Thank you for identifying this!! :-) The workaround is straightforward. I appreciate you've already worked out a long term fix! In general I do not want to pull-in conda into my run environment. This will probably turn into a separate thread, but I note that about 50% of my runs fail with "clBuildProgram failed. Returned code: -11". (CL_BUILD_PROGRAM_FAILURE) This is my big app and this doesn't happen on other platforms. The build log contains no clear errors. The referenced source cache files are not present by the time clBuildProgram returns. Build-log ( 698 bytes): warning: /Users/noah/.cache/pocl/kcache/tempfile_i2Ph3x.cl:2401:2: TODO: warning: /Users/noah/.cache/pocl/kcache/tempfile_i2Ph3x.cl:2413:2: review the below TODO warning: /Users/noah/.cache/pocl/kcache/tempfile_i2Ph3x.cl:2401:2: TODO: warning: /Users/noah/.cache/pocl/kcache/tempfile_i2Ph3x.cl:2413:2: review the below TODO Device pthread failed to build the program, log: warning: /Users/noah/.cache/pocl/kcache/tempfile_i2Ph3x.cl:2401:2: TODO: warning: /Users/noah/.cache/pocl/kcache/tempfile_i2Ph3x.cl:2413:2: review the below TODO warning: /Users/noah/.cache/pocl/kcache/tempfile_i2Ph3x.cl:2401:2: TODO: warning: /Users/noah/.cache/pocl/kcache/tempfile_i2Ph3x.cl:2413:2: review the below TODO The above output was when running under lldb debugger. Extra weird the output is different when not under the debugger. clBuildProgram failed. Returned code: -11 Build-log ( 56 bytes): Device pthread failed to build the program, log: (null) And remember, half of the time, everything works correctly. I see this output from the kernel build instead: 1 warning generated. 2 warnings generated. Feels like a race condition. I don't think I'm calling clBuildProgram in parallel, but I might be. That should be allowable though, I think. In total, 12 clBuildPrograms are called over 2-3 seconds. Warm regards, -Noah On Fri, May 20, 2022 at 10:39 AM Isuru Fernando <is...@gm...> wrote: > > Should be fixed in https://github.com/conda-forge/pocl-feedstock/pull/77 > > Isuru > > On Fri, May 20, 2022 at 12:20 PM Isuru Fernando <is...@gm...> wrote: >> >> SDKROOT is not the problem then. >> >> I think you need the `ld` executable found in `/Users/noah/miniforge3/bin` in the PATH. >> (That ld is a patched ld to workaround a setting we have added in conda to workaround >> issues with SDKROOT) >> >> This can probably be fixed in the conda package, but not sure. >> >> Isuru >> >> On Fri, May 20, 2022 at 11:49 AM Noah Reddell <noa...@gm...> wrote: >>> >>> I find no difference exporting SDKROOT at build time, run time, or both. >>> >>> ld: dynamic main executables must link with libSystem.dylib for >>> architecture arm64 >>> error: linker command failed with exit code 1 (use -v to see invocation) >>> Final linking of kernel phase_initial_condition_evaluation failed. >>> >>> (base) noah@Spitzer ~ % which xcrun >>> /usr/bin/xcrun >>> (base) noah@Spitzer ~ % xcrun --show-sdk-path >>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk >>> >>> When are you supposing SDKROOT in the environment affects behavior? >>> >>> I tried to use dtruss to catch whatever system calls are happening >>> under clEnqueueNDRangeKernel() but that system utility isn't catching >>> anything. ...MacOS security I think. >>> >>> -Noah >>> >>> On Fri, May 20, 2022 at 9:14 AM Isuru Fernando <is...@gm...> wrote: >>> > >>> > Ah, that makes sense now. Can you try doing the following? >>> > >>> > export SDKROOT=$(xcrun --show-sdk-path) >>> > >>> > (Note that the clang you are using and the one from conda that pocl is using are two different things) >>> > >>> > Isuru >>> > >>> > On Fri, May 20, 2022 at 10:41 AM Noah Reddell <noa...@gm...> wrote: >>> >> >>> >> Hi Isuru, >>> >> Thank you for maintaining the conda package and the suggestion. >>> >> >>> >> It is true I don't have the conda environment activated when building >>> >> / running my large app. I installed conda for the sole purpose of >>> >> POCL and generally use homebrew for similar needs. I'm not seeing >>> >> any difference in build/run of hello-opencl whether I have conda >>> >> activated or not. SDKROOT is not set either way. >>> >> >>> >> Starting with a fresh shell: >>> >> ---------------------------------------------- >>> >> Last login: Wed May 18 22:48:50 on ttys005 >>> >> noah@Spitzer ~ % clang -g -L/Users/noah/miniforge3/lib/ >>> >> -Wl,-rpath,/Users/noah/miniforge3/lib/ -lOpenCL >>> >> /Users/noah/Downloads/hello_opencl.c >>> >> noah@Spitzer ~ % ./a.out >>> >> Num Platforms: 1 >>> >> platform[0] name: Portable Computing Language >>> >> platform[0] Num Devices: 1 >>> >> device[0] name: pthread >>> >> function definition may only have a distinct !dbg attachment >>> >> i64 (i32)* @_Z13get_global_idj >>> >> Computed '1024/1024' correct values! >>> >> noah@Spitzer ~ % echo $SDKROOT >>> >> >>> >> noah@Spitzer ~ % source /Users/noah/miniforge3/etc/profile.d/conda.sh >>> >> noah@Spitzer ~ % conda activate >>> >> (base) noah@Spitzer ~ % echo $SDKROOT >>> >> >>> >> (base) noah@Spitzer ~ % clang -g -L/Users/noah/miniforge3/lib/ >>> >> -Wl,-rpath,/Users/noah/miniforge3/lib/ -lOpenCL >>> >> /Users/noah/Downloads/hello_opencl.c >>> >> (base) noah@Spitzer ~ % ./a.out >>> >> Num Platforms: 1 >>> >> platform[0] name: Portable Computing Language >>> >> platform[0] Num Devices: 1 >>> >> device[0] name: pthread >>> >> function definition may only have a distinct !dbg attachment >>> >> i64 (i32)* @_Z13get_global_idj >>> >> Computed '1024/1024' correct values! >>> >> >>> >> (base) noah@Spitzer ~ % which clang >>> >> /usr/bin/clang >>> >> ---------------------------------------------- >>> >> >>> >> >>> >> I'll check out your build.sh recipe. At first glance, it is not >>> >> clear to me how you're dealing with the MacOS pthread not having >>> >> pthread_barrier_t and related functions. When I tried to build POCL >>> >> last week, those pthread parts are needed. >>> >> >>> >> Cheers, >>> >> -Noah >>> >> >>> >> >>> >> On Fri, May 20, 2022 at 7:51 AM Isuru Fernando <is...@gm...> wrote: >>> >> > >>> >> > I think the issue is that you don't have the conda environment activated. >>> >> > Activating the conda environment sets the SDKROOT env variable >>> >> > so that clang can find the macOS SDK. >>> >> > >>> >> > I maintain the pocl conda package with some other maintainers. You >>> >> > can find our build scripts at https://github.com/conda-forge/pocl-feedstock/blob/main/recipe/build.sh >>> >> > >>> >> > Isuru >>> >> > >>> >> > On Fri, May 20, 2022 at 9:38 AM Noah Reddell <noa...@gm...> wrote: >>> >> >> >>> >> >> Hi, >>> >> >> I upgraded to an M1 Pro Mac and found that MacOS's built-in OpenCL >>> >> >> implementation no longer supports the CPU device. The GPU is >>> >> >> supported -- for now at least, but doesn't do fp64. >>> >> >> I'm very motivated to have a local OpenCL platform on my Mac that >>> >> >> supports CPU device. This is by far the most productive way for me to >>> >> >> first debug and develop kernels versus GPU-based debugging or on >>> >> >> remote systems. So I return to POCL but for the first time trying to >>> >> >> use it on a Mac. I'm having struggles. (latest releases MacOS >>> >> >> 12.3.1, XCode 13.4) >>> >> >> >>> >> >> My problems trying to build and run the latest POCL are more complex, >>> >> >> so I'll first mention a problem trying to use POCL acquired with the >>> >> >> Conda package manager this week. I can build and run a simple >>> >> >> hello-world program with one kernel and it computes the right answers >>> >> >> using POCL. >>> >> >> OpenCL Devices Detected: >>> >> >> Platform: Portable Computing Language >>> >> >> Type: CPU, Name: pthread >>> >> >> >>> >> >> >>> >> >> Unfortunately, when I run my large computational science application, >>> >> >> I get a runtime error shortly after the first call to >>> >> >> clEnqueueNDRangeKernel(). The function returns CL_SUCCESS, another >>> >> >> thread raises SIGABRT, I assume after the following output: >>> >> >> >>> >> >> ld: dynamic main executables must link with libSystem.dylib for >>> >> >> architecture arm64 >>> >> >> error: linker command failed with exit code 1 (use -v to see invocation) >>> >> >> Final linking of kernel physical_initial_condition_evaluation failed. >>> >> >> >>> >> >> Since my hello-world app works, yet the app I care about doesn't, my >>> >> >> leading suspicion so far is some confusion about which clang / llvm is >>> >> >> getting utilized. I've tried to be careful about what PATH is set and >>> >> >> I'm not setting DYLD_LIBRARY_PATH in any way. >>> >> >> I'd love to pass "-v" to the POCL link as suggested, but I'm not sure >>> >> >> how to do that. >>> >> >> The main application *is* linked with -lSystem so that error message >>> >> >> is probably referring to the POCL kernel build. >>> >> >> It looks like POCL_MSG_PRINT_LLVM could be helpful, but I think that >>> >> >> is only set when POCL is built, and I'm not able to build. >>> >> >> >>> >> >> Ok, so any suggestions about the above problem would be appreciated! >>> >> >> >>> >> >> >>> >> >> Sometime I'd really like to be able to build POCL myself. >>> >> >> >>> >> >> I can tell that some special steps are needed to get the latest POCL >>> >> >> to build for MacOS. Who is maintaining that Conda package? Are the >>> >> >> build steps available? >>> >> >> >>> >> >> Lesser question stemming from my failed attempts to build POCL from source: >>> >> >> Question: What is the difference between the "basic" device and >>> >> >> "pthread" device? I'm not finding documentation for either host >>> >> >> devices. >>> >> >> One reason I ask is that I found problems building "pthread" due to >>> >> >> Apple's pthread.h not including pthread_barrier support. Looks >>> >> >> like two lines in CMakeLists.txt under if(ENABLE_HOST_CPU_DEVICES) >>> >> >> could be modified to turn off the pthreads device. I also had >>> >> >> success naively providing implementations of the missing functions in >>> >> >> file pthread_scheduler.c >>> >> >> >>> >> >> >>> >> >> >>> >> >> Warm regards, >>> >> >> >>> >> >> Noah >>> >> >> >>> >> >> >>> >> >> _______________________________________________ >>> >> >> pocl-devel mailing list >>> >> >> poc...@li... >>> >> >> https://lists.sourceforge.net/lists/listinfo/pocl-devel >>> >> > >>> >> > _______________________________________________ >>> >> > pocl-devel mailing list >>> >> > poc...@li... >>> >> > https://lists.sourceforge.net/lists/listinfo/pocl-devel >>> >> >>> >> >>> >> _______________________________________________ >>> >> pocl-devel mailing list >>> >> poc...@li... >>> >> https://lists.sourceforge.net/lists/listinfo/pocl-devel >>> > >>> > _______________________________________________ >>> > pocl-devel mailing list >>> > poc...@li... >>> > https://lists.sourceforge.net/lists/listinfo/pocl-devel >>> >>> >>> _______________________________________________ >>> pocl-devel mailing list >>> poc...@li... >>> https://lists.sourceforge.net/lists/listinfo/pocl-devel > > _______________________________________________ > pocl-devel mailing list > poc...@li... > https://lists.sourceforge.net/lists/listinfo/pocl-devel |
From: Jan S. (TAU) <jan...@tu...> - 2022-05-20 17:49:24
|
Hello all, LLVM 14.0 has been out for a while so a new PoCL release is in order. In addition, there is now initial support for OpenCL 3.0 (not conformant). I’ve created RC1: https://github.com/pocl/pocl/releases/tag/v3.0-RC1 Please test and report your results here: https://github.com/pocl/pocl/wiki/Release-testing-of-pocl-3.0 or file issues on GitHub. Regards, — Jan |
From: Isuru F. <is...@gm...> - 2022-05-20 17:39:00
|
Should be fixed in https://github.com/conda-forge/pocl-feedstock/pull/77 Isuru On Fri, May 20, 2022 at 12:20 PM Isuru Fernando <is...@gm...> wrote: > SDKROOT is not the problem then. > > I think you need the `ld` executable found in `/Users/noah/miniforge3/bin` > in the PATH. > (That ld is a patched ld to workaround a setting we have added in conda to > workaround > issues with SDKROOT) > > This can probably be fixed in the conda package, but not sure. > > Isuru > > On Fri, May 20, 2022 at 11:49 AM Noah Reddell <noa...@gm...> > wrote: > >> I find no difference exporting SDKROOT at build time, run time, or both. >> >> ld: dynamic main executables must link with libSystem.dylib for >> architecture arm64 >> error: linker command failed with exit code 1 (use -v to see invocation) >> Final linking of kernel phase_initial_condition_evaluation failed. >> >> (base) noah@Spitzer ~ % which xcrun >> /usr/bin/xcrun >> (base) noah@Spitzer ~ % xcrun --show-sdk-path >> >> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk >> >> When are you supposing SDKROOT in the environment affects behavior? >> >> I tried to use dtruss to catch whatever system calls are happening >> under clEnqueueNDRangeKernel() but that system utility isn't catching >> anything. ...MacOS security I think. >> >> -Noah >> >> On Fri, May 20, 2022 at 9:14 AM Isuru Fernando <is...@gm...> wrote: >> > >> > Ah, that makes sense now. Can you try doing the following? >> > >> > export SDKROOT=$(xcrun --show-sdk-path) >> > >> > (Note that the clang you are using and the one from conda that pocl is >> using are two different things) >> > >> > Isuru >> > >> > On Fri, May 20, 2022 at 10:41 AM Noah Reddell < >> noa...@gm...> wrote: >> >> >> >> Hi Isuru, >> >> Thank you for maintaining the conda package and the suggestion. >> >> >> >> It is true I don't have the conda environment activated when building >> >> / running my large app. I installed conda for the sole purpose of >> >> POCL and generally use homebrew for similar needs. I'm not seeing >> >> any difference in build/run of hello-opencl whether I have conda >> >> activated or not. SDKROOT is not set either way. >> >> >> >> Starting with a fresh shell: >> >> ---------------------------------------------- >> >> Last login: Wed May 18 22:48:50 on ttys005 >> >> noah@Spitzer ~ % clang -g -L/Users/noah/miniforge3/lib/ >> >> -Wl,-rpath,/Users/noah/miniforge3/lib/ -lOpenCL >> >> /Users/noah/Downloads/hello_opencl.c >> >> noah@Spitzer ~ % ./a.out >> >> Num Platforms: 1 >> >> platform[0] name: Portable Computing Language >> >> platform[0] Num Devices: 1 >> >> device[0] name: pthread >> >> function definition may only have a distinct !dbg attachment >> >> i64 (i32)* @_Z13get_global_idj >> >> Computed '1024/1024' correct values! >> >> noah@Spitzer ~ % echo $SDKROOT >> >> >> >> noah@Spitzer ~ % source /Users/noah/miniforge3/etc/profile.d/conda.sh >> >> noah@Spitzer ~ % conda activate >> >> (base) noah@Spitzer ~ % echo $SDKROOT >> >> >> >> (base) noah@Spitzer ~ % clang -g -L/Users/noah/miniforge3/lib/ >> >> -Wl,-rpath,/Users/noah/miniforge3/lib/ -lOpenCL >> >> /Users/noah/Downloads/hello_opencl.c >> >> (base) noah@Spitzer ~ % ./a.out >> >> Num Platforms: 1 >> >> platform[0] name: Portable Computing Language >> >> platform[0] Num Devices: 1 >> >> device[0] name: pthread >> >> function definition may only have a distinct !dbg attachment >> >> i64 (i32)* @_Z13get_global_idj >> >> Computed '1024/1024' correct values! >> >> >> >> (base) noah@Spitzer ~ % which clang >> >> /usr/bin/clang >> >> ---------------------------------------------- >> >> >> >> >> >> I'll check out your build.sh recipe. At first glance, it is not >> >> clear to me how you're dealing with the MacOS pthread not having >> >> pthread_barrier_t and related functions. When I tried to build POCL >> >> last week, those pthread parts are needed. >> >> >> >> Cheers, >> >> -Noah >> >> >> >> >> >> On Fri, May 20, 2022 at 7:51 AM Isuru Fernando <is...@gm...> >> wrote: >> >> > >> >> > I think the issue is that you don't have the conda environment >> activated. >> >> > Activating the conda environment sets the SDKROOT env variable >> >> > so that clang can find the macOS SDK. >> >> > >> >> > I maintain the pocl conda package with some other maintainers. You >> >> > can find our build scripts at >> https://github.com/conda-forge/pocl-feedstock/blob/main/recipe/build.sh >> >> > >> >> > Isuru >> >> > >> >> > On Fri, May 20, 2022 at 9:38 AM Noah Reddell < >> noa...@gm...> wrote: >> >> >> >> >> >> Hi, >> >> >> I upgraded to an M1 Pro Mac and found that MacOS's built-in >> OpenCL >> >> >> implementation no longer supports the CPU device. The GPU is >> >> >> supported -- for now at least, but doesn't do fp64. >> >> >> I'm very motivated to have a local OpenCL platform on my Mac that >> >> >> supports CPU device. This is by far the most productive way for me >> to >> >> >> first debug and develop kernels versus GPU-based debugging or on >> >> >> remote systems. So I return to POCL but for the first time trying >> to >> >> >> use it on a Mac. I'm having struggles. (latest releases MacOS >> >> >> 12.3.1, XCode 13.4) >> >> >> >> >> >> My problems trying to build and run the latest POCL are more >> complex, >> >> >> so I'll first mention a problem trying to use POCL acquired with the >> >> >> Conda package manager this week. I can build and run a simple >> >> >> hello-world program with one kernel and it computes the right >> answers >> >> >> using POCL. >> >> >> OpenCL Devices Detected: >> >> >> Platform: Portable Computing Language >> >> >> Type: CPU, Name: pthread >> >> >> >> >> >> >> >> >> Unfortunately, when I run my large computational science >> application, >> >> >> I get a runtime error shortly after the first call to >> >> >> clEnqueueNDRangeKernel(). The function returns CL_SUCCESS, another >> >> >> thread raises SIGABRT, I assume after the following output: >> >> >> >> >> >> ld: dynamic main executables must link with libSystem.dylib for >> >> >> architecture arm64 >> >> >> error: linker command failed with exit code 1 (use -v to see >> invocation) >> >> >> Final linking of kernel physical_initial_condition_evaluation >> failed. >> >> >> >> >> >> Since my hello-world app works, yet the app I care about doesn't, >> my >> >> >> leading suspicion so far is some confusion about which clang / llvm >> is >> >> >> getting utilized. I've tried to be careful about what PATH is set >> and >> >> >> I'm not setting DYLD_LIBRARY_PATH in any way. >> >> >> I'd love to pass "-v" to the POCL link as suggested, but I'm not >> sure >> >> >> how to do that. >> >> >> The main application *is* linked with -lSystem so that error message >> >> >> is probably referring to the POCL kernel build. >> >> >> It looks like POCL_MSG_PRINT_LLVM could be helpful, but I think that >> >> >> is only set when POCL is built, and I'm not able to build. >> >> >> >> >> >> Ok, so any suggestions about the above problem would be >> appreciated! >> >> >> >> >> >> >> >> >> Sometime I'd really like to be able to build POCL myself. >> >> >> >> >> >> I can tell that some special steps are needed to get the latest POCL >> >> >> to build for MacOS. Who is maintaining that Conda package? Are >> the >> >> >> build steps available? >> >> >> >> >> >> Lesser question stemming from my failed attempts to build POCL >> from source: >> >> >> Question: What is the difference between the "basic" device and >> >> >> "pthread" device? I'm not finding documentation for either host >> >> >> devices. >> >> >> One reason I ask is that I found problems building "pthread" due >> to >> >> >> Apple's pthread.h not including pthread_barrier support. Looks >> >> >> like two lines in CMakeLists.txt under if(ENABLE_HOST_CPU_DEVICES) >> >> >> could be modified to turn off the pthreads device. I also had >> >> >> success naively providing implementations of the missing functions >> in >> >> >> file pthread_scheduler.c >> >> >> >> >> >> >> >> >> >> >> >> Warm regards, >> >> >> >> >> >> Noah >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> pocl-devel mailing list >> >> >> poc...@li... >> >> >> https://lists.sourceforge.net/lists/listinfo/pocl-devel >> >> > >> >> > _______________________________________________ >> >> > pocl-devel mailing list >> >> > poc...@li... >> >> > https://lists.sourceforge.net/lists/listinfo/pocl-devel >> >> >> >> >> >> _______________________________________________ >> >> pocl-devel mailing list >> >> poc...@li... >> >> https://lists.sourceforge.net/lists/listinfo/pocl-devel >> > >> > _______________________________________________ >> > pocl-devel mailing list >> > poc...@li... >> > https://lists.sourceforge.net/lists/listinfo/pocl-devel >> >> >> _______________________________________________ >> pocl-devel mailing list >> poc...@li... >> https://lists.sourceforge.net/lists/listinfo/pocl-devel >> > |
From: Isuru F. <is...@gm...> - 2022-05-20 17:21:15
|
SDKROOT is not the problem then. I think you need the `ld` executable found in `/Users/noah/miniforge3/bin` in the PATH. (That ld is a patched ld to workaround a setting we have added in conda to workaround issues with SDKROOT) This can probably be fixed in the conda package, but not sure. Isuru On Fri, May 20, 2022 at 11:49 AM Noah Reddell <noa...@gm...> wrote: > I find no difference exporting SDKROOT at build time, run time, or both. > > ld: dynamic main executables must link with libSystem.dylib for > architecture arm64 > error: linker command failed with exit code 1 (use -v to see invocation) > Final linking of kernel phase_initial_condition_evaluation failed. > > (base) noah@Spitzer ~ % which xcrun > /usr/bin/xcrun > (base) noah@Spitzer ~ % xcrun --show-sdk-path > > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk > > When are you supposing SDKROOT in the environment affects behavior? > > I tried to use dtruss to catch whatever system calls are happening > under clEnqueueNDRangeKernel() but that system utility isn't catching > anything. ...MacOS security I think. > > -Noah > > On Fri, May 20, 2022 at 9:14 AM Isuru Fernando <is...@gm...> wrote: > > > > Ah, that makes sense now. Can you try doing the following? > > > > export SDKROOT=$(xcrun --show-sdk-path) > > > > (Note that the clang you are using and the one from conda that pocl is > using are two different things) > > > > Isuru > > > > On Fri, May 20, 2022 at 10:41 AM Noah Reddell < > noa...@gm...> wrote: > >> > >> Hi Isuru, > >> Thank you for maintaining the conda package and the suggestion. > >> > >> It is true I don't have the conda environment activated when building > >> / running my large app. I installed conda for the sole purpose of > >> POCL and generally use homebrew for similar needs. I'm not seeing > >> any difference in build/run of hello-opencl whether I have conda > >> activated or not. SDKROOT is not set either way. > >> > >> Starting with a fresh shell: > >> ---------------------------------------------- > >> Last login: Wed May 18 22:48:50 on ttys005 > >> noah@Spitzer ~ % clang -g -L/Users/noah/miniforge3/lib/ > >> -Wl,-rpath,/Users/noah/miniforge3/lib/ -lOpenCL > >> /Users/noah/Downloads/hello_opencl.c > >> noah@Spitzer ~ % ./a.out > >> Num Platforms: 1 > >> platform[0] name: Portable Computing Language > >> platform[0] Num Devices: 1 > >> device[0] name: pthread > >> function definition may only have a distinct !dbg attachment > >> i64 (i32)* @_Z13get_global_idj > >> Computed '1024/1024' correct values! > >> noah@Spitzer ~ % echo $SDKROOT > >> > >> noah@Spitzer ~ % source /Users/noah/miniforge3/etc/profile.d/conda.sh > >> noah@Spitzer ~ % conda activate > >> (base) noah@Spitzer ~ % echo $SDKROOT > >> > >> (base) noah@Spitzer ~ % clang -g -L/Users/noah/miniforge3/lib/ > >> -Wl,-rpath,/Users/noah/miniforge3/lib/ -lOpenCL > >> /Users/noah/Downloads/hello_opencl.c > >> (base) noah@Spitzer ~ % ./a.out > >> Num Platforms: 1 > >> platform[0] name: Portable Computing Language > >> platform[0] Num Devices: 1 > >> device[0] name: pthread > >> function definition may only have a distinct !dbg attachment > >> i64 (i32)* @_Z13get_global_idj > >> Computed '1024/1024' correct values! > >> > >> (base) noah@Spitzer ~ % which clang > >> /usr/bin/clang > >> ---------------------------------------------- > >> > >> > >> I'll check out your build.sh recipe. At first glance, it is not > >> clear to me how you're dealing with the MacOS pthread not having > >> pthread_barrier_t and related functions. When I tried to build POCL > >> last week, those pthread parts are needed. > >> > >> Cheers, > >> -Noah > >> > >> > >> On Fri, May 20, 2022 at 7:51 AM Isuru Fernando <is...@gm...> > wrote: > >> > > >> > I think the issue is that you don't have the conda environment > activated. > >> > Activating the conda environment sets the SDKROOT env variable > >> > so that clang can find the macOS SDK. > >> > > >> > I maintain the pocl conda package with some other maintainers. You > >> > can find our build scripts at > https://github.com/conda-forge/pocl-feedstock/blob/main/recipe/build.sh > >> > > >> > Isuru > >> > > >> > On Fri, May 20, 2022 at 9:38 AM Noah Reddell < > noa...@gm...> wrote: > >> >> > >> >> Hi, > >> >> I upgraded to an M1 Pro Mac and found that MacOS's built-in OpenCL > >> >> implementation no longer supports the CPU device. The GPU is > >> >> supported -- for now at least, but doesn't do fp64. > >> >> I'm very motivated to have a local OpenCL platform on my Mac that > >> >> supports CPU device. This is by far the most productive way for me > to > >> >> first debug and develop kernels versus GPU-based debugging or on > >> >> remote systems. So I return to POCL but for the first time trying > to > >> >> use it on a Mac. I'm having struggles. (latest releases MacOS > >> >> 12.3.1, XCode 13.4) > >> >> > >> >> My problems trying to build and run the latest POCL are more complex, > >> >> so I'll first mention a problem trying to use POCL acquired with the > >> >> Conda package manager this week. I can build and run a simple > >> >> hello-world program with one kernel and it computes the right answers > >> >> using POCL. > >> >> OpenCL Devices Detected: > >> >> Platform: Portable Computing Language > >> >> Type: CPU, Name: pthread > >> >> > >> >> > >> >> Unfortunately, when I run my large computational science application, > >> >> I get a runtime error shortly after the first call to > >> >> clEnqueueNDRangeKernel(). The function returns CL_SUCCESS, another > >> >> thread raises SIGABRT, I assume after the following output: > >> >> > >> >> ld: dynamic main executables must link with libSystem.dylib for > >> >> architecture arm64 > >> >> error: linker command failed with exit code 1 (use -v to see > invocation) > >> >> Final linking of kernel physical_initial_condition_evaluation failed. > >> >> > >> >> Since my hello-world app works, yet the app I care about doesn't, my > >> >> leading suspicion so far is some confusion about which clang / llvm > is > >> >> getting utilized. I've tried to be careful about what PATH is set > and > >> >> I'm not setting DYLD_LIBRARY_PATH in any way. > >> >> I'd love to pass "-v" to the POCL link as suggested, but I'm not sure > >> >> how to do that. > >> >> The main application *is* linked with -lSystem so that error message > >> >> is probably referring to the POCL kernel build. > >> >> It looks like POCL_MSG_PRINT_LLVM could be helpful, but I think that > >> >> is only set when POCL is built, and I'm not able to build. > >> >> > >> >> Ok, so any suggestions about the above problem would be appreciated! > >> >> > >> >> > >> >> Sometime I'd really like to be able to build POCL myself. > >> >> > >> >> I can tell that some special steps are needed to get the latest POCL > >> >> to build for MacOS. Who is maintaining that Conda package? Are the > >> >> build steps available? > >> >> > >> >> Lesser question stemming from my failed attempts to build POCL > from source: > >> >> Question: What is the difference between the "basic" device and > >> >> "pthread" device? I'm not finding documentation for either host > >> >> devices. > >> >> One reason I ask is that I found problems building "pthread" due > to > >> >> Apple's pthread.h not including pthread_barrier support. Looks > >> >> like two lines in CMakeLists.txt under if(ENABLE_HOST_CPU_DEVICES) > >> >> could be modified to turn off the pthreads device. I also had > >> >> success naively providing implementations of the missing functions > in > >> >> file pthread_scheduler.c > >> >> > >> >> > >> >> > >> >> Warm regards, > >> >> > >> >> Noah > >> >> > >> >> > >> >> _______________________________________________ > >> >> pocl-devel mailing list > >> >> poc...@li... > >> >> https://lists.sourceforge.net/lists/listinfo/pocl-devel > >> > > >> > _______________________________________________ > >> > pocl-devel mailing list > >> > poc...@li... > >> > https://lists.sourceforge.net/lists/listinfo/pocl-devel > >> > >> > >> _______________________________________________ > >> pocl-devel mailing list > >> poc...@li... > >> https://lists.sourceforge.net/lists/listinfo/pocl-devel > > > > _______________________________________________ > > pocl-devel mailing list > > poc...@li... > > https://lists.sourceforge.net/lists/listinfo/pocl-devel > > > _______________________________________________ > pocl-devel mailing list > poc...@li... > https://lists.sourceforge.net/lists/listinfo/pocl-devel > |
From: Noah R. <noa...@gm...> - 2022-05-20 16:48:26
|
I find no difference exporting SDKROOT at build time, run time, or both. ld: dynamic main executables must link with libSystem.dylib for architecture arm64 error: linker command failed with exit code 1 (use -v to see invocation) Final linking of kernel phase_initial_condition_evaluation failed. (base) noah@Spitzer ~ % which xcrun /usr/bin/xcrun (base) noah@Spitzer ~ % xcrun --show-sdk-path /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk When are you supposing SDKROOT in the environment affects behavior? I tried to use dtruss to catch whatever system calls are happening under clEnqueueNDRangeKernel() but that system utility isn't catching anything. ...MacOS security I think. -Noah On Fri, May 20, 2022 at 9:14 AM Isuru Fernando <is...@gm...> wrote: > > Ah, that makes sense now. Can you try doing the following? > > export SDKROOT=$(xcrun --show-sdk-path) > > (Note that the clang you are using and the one from conda that pocl is using are two different things) > > Isuru > > On Fri, May 20, 2022 at 10:41 AM Noah Reddell <noa...@gm...> wrote: >> >> Hi Isuru, >> Thank you for maintaining the conda package and the suggestion. >> >> It is true I don't have the conda environment activated when building >> / running my large app. I installed conda for the sole purpose of >> POCL and generally use homebrew for similar needs. I'm not seeing >> any difference in build/run of hello-opencl whether I have conda >> activated or not. SDKROOT is not set either way. >> >> Starting with a fresh shell: >> ---------------------------------------------- >> Last login: Wed May 18 22:48:50 on ttys005 >> noah@Spitzer ~ % clang -g -L/Users/noah/miniforge3/lib/ >> -Wl,-rpath,/Users/noah/miniforge3/lib/ -lOpenCL >> /Users/noah/Downloads/hello_opencl.c >> noah@Spitzer ~ % ./a.out >> Num Platforms: 1 >> platform[0] name: Portable Computing Language >> platform[0] Num Devices: 1 >> device[0] name: pthread >> function definition may only have a distinct !dbg attachment >> i64 (i32)* @_Z13get_global_idj >> Computed '1024/1024' correct values! >> noah@Spitzer ~ % echo $SDKROOT >> >> noah@Spitzer ~ % source /Users/noah/miniforge3/etc/profile.d/conda.sh >> noah@Spitzer ~ % conda activate >> (base) noah@Spitzer ~ % echo $SDKROOT >> >> (base) noah@Spitzer ~ % clang -g -L/Users/noah/miniforge3/lib/ >> -Wl,-rpath,/Users/noah/miniforge3/lib/ -lOpenCL >> /Users/noah/Downloads/hello_opencl.c >> (base) noah@Spitzer ~ % ./a.out >> Num Platforms: 1 >> platform[0] name: Portable Computing Language >> platform[0] Num Devices: 1 >> device[0] name: pthread >> function definition may only have a distinct !dbg attachment >> i64 (i32)* @_Z13get_global_idj >> Computed '1024/1024' correct values! >> >> (base) noah@Spitzer ~ % which clang >> /usr/bin/clang >> ---------------------------------------------- >> >> >> I'll check out your build.sh recipe. At first glance, it is not >> clear to me how you're dealing with the MacOS pthread not having >> pthread_barrier_t and related functions. When I tried to build POCL >> last week, those pthread parts are needed. >> >> Cheers, >> -Noah >> >> >> On Fri, May 20, 2022 at 7:51 AM Isuru Fernando <is...@gm...> wrote: >> > >> > I think the issue is that you don't have the conda environment activated. >> > Activating the conda environment sets the SDKROOT env variable >> > so that clang can find the macOS SDK. >> > >> > I maintain the pocl conda package with some other maintainers. You >> > can find our build scripts at https://github.com/conda-forge/pocl-feedstock/blob/main/recipe/build.sh >> > >> > Isuru >> > >> > On Fri, May 20, 2022 at 9:38 AM Noah Reddell <noa...@gm...> wrote: >> >> >> >> Hi, >> >> I upgraded to an M1 Pro Mac and found that MacOS's built-in OpenCL >> >> implementation no longer supports the CPU device. The GPU is >> >> supported -- for now at least, but doesn't do fp64. >> >> I'm very motivated to have a local OpenCL platform on my Mac that >> >> supports CPU device. This is by far the most productive way for me to >> >> first debug and develop kernels versus GPU-based debugging or on >> >> remote systems. So I return to POCL but for the first time trying to >> >> use it on a Mac. I'm having struggles. (latest releases MacOS >> >> 12.3.1, XCode 13.4) >> >> >> >> My problems trying to build and run the latest POCL are more complex, >> >> so I'll first mention a problem trying to use POCL acquired with the >> >> Conda package manager this week. I can build and run a simple >> >> hello-world program with one kernel and it computes the right answers >> >> using POCL. >> >> OpenCL Devices Detected: >> >> Platform: Portable Computing Language >> >> Type: CPU, Name: pthread >> >> >> >> >> >> Unfortunately, when I run my large computational science application, >> >> I get a runtime error shortly after the first call to >> >> clEnqueueNDRangeKernel(). The function returns CL_SUCCESS, another >> >> thread raises SIGABRT, I assume after the following output: >> >> >> >> ld: dynamic main executables must link with libSystem.dylib for >> >> architecture arm64 >> >> error: linker command failed with exit code 1 (use -v to see invocation) >> >> Final linking of kernel physical_initial_condition_evaluation failed. >> >> >> >> Since my hello-world app works, yet the app I care about doesn't, my >> >> leading suspicion so far is some confusion about which clang / llvm is >> >> getting utilized. I've tried to be careful about what PATH is set and >> >> I'm not setting DYLD_LIBRARY_PATH in any way. >> >> I'd love to pass "-v" to the POCL link as suggested, but I'm not sure >> >> how to do that. >> >> The main application *is* linked with -lSystem so that error message >> >> is probably referring to the POCL kernel build. >> >> It looks like POCL_MSG_PRINT_LLVM could be helpful, but I think that >> >> is only set when POCL is built, and I'm not able to build. >> >> >> >> Ok, so any suggestions about the above problem would be appreciated! >> >> >> >> >> >> Sometime I'd really like to be able to build POCL myself. >> >> >> >> I can tell that some special steps are needed to get the latest POCL >> >> to build for MacOS. Who is maintaining that Conda package? Are the >> >> build steps available? >> >> >> >> Lesser question stemming from my failed attempts to build POCL from source: >> >> Question: What is the difference between the "basic" device and >> >> "pthread" device? I'm not finding documentation for either host >> >> devices. >> >> One reason I ask is that I found problems building "pthread" due to >> >> Apple's pthread.h not including pthread_barrier support. Looks >> >> like two lines in CMakeLists.txt under if(ENABLE_HOST_CPU_DEVICES) >> >> could be modified to turn off the pthreads device. I also had >> >> success naively providing implementations of the missing functions in >> >> file pthread_scheduler.c >> >> >> >> >> >> >> >> Warm regards, >> >> >> >> Noah >> >> >> >> >> >> _______________________________________________ >> >> pocl-devel mailing list >> >> poc...@li... >> >> https://lists.sourceforge.net/lists/listinfo/pocl-devel >> > >> > _______________________________________________ >> > pocl-devel mailing list >> > poc...@li... >> > https://lists.sourceforge.net/lists/listinfo/pocl-devel >> >> >> _______________________________________________ >> pocl-devel mailing list >> poc...@li... >> https://lists.sourceforge.net/lists/listinfo/pocl-devel > > _______________________________________________ > pocl-devel mailing list > poc...@li... > https://lists.sourceforge.net/lists/listinfo/pocl-devel |
From: Isuru F. <is...@gm...> - 2022-05-20 16:13:45
|
Ah, that makes sense now. Can you try doing the following? export SDKROOT=$(xcrun --show-sdk-path) (Note that the clang you are using and the one from conda that pocl is using are two different things) Isuru On Fri, May 20, 2022 at 10:41 AM Noah Reddell <noa...@gm...> wrote: > Hi Isuru, > Thank you for maintaining the conda package and the suggestion. > > It is true I don't have the conda environment activated when building > / running my large app. I installed conda for the sole purpose of > POCL and generally use homebrew for similar needs. I'm not seeing > any difference in build/run of hello-opencl whether I have conda > activated or not. SDKROOT is not set either way. > > Starting with a fresh shell: > ---------------------------------------------- > Last login: Wed May 18 22:48:50 on ttys005 > noah@Spitzer ~ % clang -g -L/Users/noah/miniforge3/lib/ > -Wl,-rpath,/Users/noah/miniforge3/lib/ -lOpenCL > /Users/noah/Downloads/hello_opencl.c > noah@Spitzer ~ % ./a.out > Num Platforms: 1 > platform[0] name: Portable Computing Language > platform[0] Num Devices: 1 > device[0] name: pthread > function definition may only have a distinct !dbg attachment > i64 (i32)* @_Z13get_global_idj > Computed '1024/1024' correct values! > noah@Spitzer ~ % echo $SDKROOT > > noah@Spitzer ~ % source /Users/noah/miniforge3/etc/profile.d/conda.sh > noah@Spitzer ~ % conda activate > (base) noah@Spitzer ~ % echo $SDKROOT > > (base) noah@Spitzer ~ % clang -g -L/Users/noah/miniforge3/lib/ > -Wl,-rpath,/Users/noah/miniforge3/lib/ -lOpenCL > /Users/noah/Downloads/hello_opencl.c > (base) noah@Spitzer ~ % ./a.out > Num Platforms: 1 > platform[0] name: Portable Computing Language > platform[0] Num Devices: 1 > device[0] name: pthread > function definition may only have a distinct !dbg attachment > i64 (i32)* @_Z13get_global_idj > Computed '1024/1024' correct values! > > (base) noah@Spitzer ~ % which clang > /usr/bin/clang > ---------------------------------------------- > > > I'll check out your build.sh recipe. At first glance, it is not > clear to me how you're dealing with the MacOS pthread not having > pthread_barrier_t and related functions. When I tried to build POCL > last week, those pthread parts are needed. > > Cheers, > -Noah > > > On Fri, May 20, 2022 at 7:51 AM Isuru Fernando <is...@gm...> wrote: > > > > I think the issue is that you don't have the conda environment activated. > > Activating the conda environment sets the SDKROOT env variable > > so that clang can find the macOS SDK. > > > > I maintain the pocl conda package with some other maintainers. You > > can find our build scripts at > https://github.com/conda-forge/pocl-feedstock/blob/main/recipe/build.sh > > > > Isuru > > > > On Fri, May 20, 2022 at 9:38 AM Noah Reddell < > noa...@gm...> wrote: > >> > >> Hi, > >> I upgraded to an M1 Pro Mac and found that MacOS's built-in OpenCL > >> implementation no longer supports the CPU device. The GPU is > >> supported -- for now at least, but doesn't do fp64. > >> I'm very motivated to have a local OpenCL platform on my Mac that > >> supports CPU device. This is by far the most productive way for me to > >> first debug and develop kernels versus GPU-based debugging or on > >> remote systems. So I return to POCL but for the first time trying to > >> use it on a Mac. I'm having struggles. (latest releases MacOS > >> 12.3.1, XCode 13.4) > >> > >> My problems trying to build and run the latest POCL are more complex, > >> so I'll first mention a problem trying to use POCL acquired with the > >> Conda package manager this week. I can build and run a simple > >> hello-world program with one kernel and it computes the right answers > >> using POCL. > >> OpenCL Devices Detected: > >> Platform: Portable Computing Language > >> Type: CPU, Name: pthread > >> > >> > >> Unfortunately, when I run my large computational science application, > >> I get a runtime error shortly after the first call to > >> clEnqueueNDRangeKernel(). The function returns CL_SUCCESS, another > >> thread raises SIGABRT, I assume after the following output: > >> > >> ld: dynamic main executables must link with libSystem.dylib for > >> architecture arm64 > >> error: linker command failed with exit code 1 (use -v to see invocation) > >> Final linking of kernel physical_initial_condition_evaluation failed. > >> > >> Since my hello-world app works, yet the app I care about doesn't, my > >> leading suspicion so far is some confusion about which clang / llvm is > >> getting utilized. I've tried to be careful about what PATH is set and > >> I'm not setting DYLD_LIBRARY_PATH in any way. > >> I'd love to pass "-v" to the POCL link as suggested, but I'm not sure > >> how to do that. > >> The main application *is* linked with -lSystem so that error message > >> is probably referring to the POCL kernel build. > >> It looks like POCL_MSG_PRINT_LLVM could be helpful, but I think that > >> is only set when POCL is built, and I'm not able to build. > >> > >> Ok, so any suggestions about the above problem would be appreciated! > >> > >> > >> Sometime I'd really like to be able to build POCL myself. > >> > >> I can tell that some special steps are needed to get the latest POCL > >> to build for MacOS. Who is maintaining that Conda package? Are the > >> build steps available? > >> > >> Lesser question stemming from my failed attempts to build POCL from > source: > >> Question: What is the difference between the "basic" device and > >> "pthread" device? I'm not finding documentation for either host > >> devices. > >> One reason I ask is that I found problems building "pthread" due to > >> Apple's pthread.h not including pthread_barrier support. Looks > >> like two lines in CMakeLists.txt under if(ENABLE_HOST_CPU_DEVICES) > >> could be modified to turn off the pthreads device. I also had > >> success naively providing implementations of the missing functions in > >> file pthread_scheduler.c > >> > >> > >> > >> Warm regards, > >> > >> Noah > >> > >> > >> _______________________________________________ > >> pocl-devel mailing list > >> poc...@li... > >> https://lists.sourceforge.net/lists/listinfo/pocl-devel > > > > _______________________________________________ > > pocl-devel mailing list > > poc...@li... > > https://lists.sourceforge.net/lists/listinfo/pocl-devel > > > _______________________________________________ > pocl-devel mailing list > poc...@li... > https://lists.sourceforge.net/lists/listinfo/pocl-devel > |
From: Noah R. <noa...@gm...> - 2022-05-20 15:40:57
|
Hi Isuru, Thank you for maintaining the conda package and the suggestion. It is true I don't have the conda environment activated when building / running my large app. I installed conda for the sole purpose of POCL and generally use homebrew for similar needs. I'm not seeing any difference in build/run of hello-opencl whether I have conda activated or not. SDKROOT is not set either way. Starting with a fresh shell: ---------------------------------------------- Last login: Wed May 18 22:48:50 on ttys005 noah@Spitzer ~ % clang -g -L/Users/noah/miniforge3/lib/ -Wl,-rpath,/Users/noah/miniforge3/lib/ -lOpenCL /Users/noah/Downloads/hello_opencl.c noah@Spitzer ~ % ./a.out Num Platforms: 1 platform[0] name: Portable Computing Language platform[0] Num Devices: 1 device[0] name: pthread function definition may only have a distinct !dbg attachment i64 (i32)* @_Z13get_global_idj Computed '1024/1024' correct values! noah@Spitzer ~ % echo $SDKROOT noah@Spitzer ~ % source /Users/noah/miniforge3/etc/profile.d/conda.sh noah@Spitzer ~ % conda activate (base) noah@Spitzer ~ % echo $SDKROOT (base) noah@Spitzer ~ % clang -g -L/Users/noah/miniforge3/lib/ -Wl,-rpath,/Users/noah/miniforge3/lib/ -lOpenCL /Users/noah/Downloads/hello_opencl.c (base) noah@Spitzer ~ % ./a.out Num Platforms: 1 platform[0] name: Portable Computing Language platform[0] Num Devices: 1 device[0] name: pthread function definition may only have a distinct !dbg attachment i64 (i32)* @_Z13get_global_idj Computed '1024/1024' correct values! (base) noah@Spitzer ~ % which clang /usr/bin/clang ---------------------------------------------- I'll check out your build.sh recipe. At first glance, it is not clear to me how you're dealing with the MacOS pthread not having pthread_barrier_t and related functions. When I tried to build POCL last week, those pthread parts are needed. Cheers, -Noah On Fri, May 20, 2022 at 7:51 AM Isuru Fernando <is...@gm...> wrote: > > I think the issue is that you don't have the conda environment activated. > Activating the conda environment sets the SDKROOT env variable > so that clang can find the macOS SDK. > > I maintain the pocl conda package with some other maintainers. You > can find our build scripts at https://github.com/conda-forge/pocl-feedstock/blob/main/recipe/build.sh > > Isuru > > On Fri, May 20, 2022 at 9:38 AM Noah Reddell <noa...@gm...> wrote: >> >> Hi, >> I upgraded to an M1 Pro Mac and found that MacOS's built-in OpenCL >> implementation no longer supports the CPU device. The GPU is >> supported -- for now at least, but doesn't do fp64. >> I'm very motivated to have a local OpenCL platform on my Mac that >> supports CPU device. This is by far the most productive way for me to >> first debug and develop kernels versus GPU-based debugging or on >> remote systems. So I return to POCL but for the first time trying to >> use it on a Mac. I'm having struggles. (latest releases MacOS >> 12.3.1, XCode 13.4) >> >> My problems trying to build and run the latest POCL are more complex, >> so I'll first mention a problem trying to use POCL acquired with the >> Conda package manager this week. I can build and run a simple >> hello-world program with one kernel and it computes the right answers >> using POCL. >> OpenCL Devices Detected: >> Platform: Portable Computing Language >> Type: CPU, Name: pthread >> >> >> Unfortunately, when I run my large computational science application, >> I get a runtime error shortly after the first call to >> clEnqueueNDRangeKernel(). The function returns CL_SUCCESS, another >> thread raises SIGABRT, I assume after the following output: >> >> ld: dynamic main executables must link with libSystem.dylib for >> architecture arm64 >> error: linker command failed with exit code 1 (use -v to see invocation) >> Final linking of kernel physical_initial_condition_evaluation failed. >> >> Since my hello-world app works, yet the app I care about doesn't, my >> leading suspicion so far is some confusion about which clang / llvm is >> getting utilized. I've tried to be careful about what PATH is set and >> I'm not setting DYLD_LIBRARY_PATH in any way. >> I'd love to pass "-v" to the POCL link as suggested, but I'm not sure >> how to do that. >> The main application *is* linked with -lSystem so that error message >> is probably referring to the POCL kernel build. >> It looks like POCL_MSG_PRINT_LLVM could be helpful, but I think that >> is only set when POCL is built, and I'm not able to build. >> >> Ok, so any suggestions about the above problem would be appreciated! >> >> >> Sometime I'd really like to be able to build POCL myself. >> >> I can tell that some special steps are needed to get the latest POCL >> to build for MacOS. Who is maintaining that Conda package? Are the >> build steps available? >> >> Lesser question stemming from my failed attempts to build POCL from source: >> Question: What is the difference between the "basic" device and >> "pthread" device? I'm not finding documentation for either host >> devices. >> One reason I ask is that I found problems building "pthread" due to >> Apple's pthread.h not including pthread_barrier support. Looks >> like two lines in CMakeLists.txt under if(ENABLE_HOST_CPU_DEVICES) >> could be modified to turn off the pthreads device. I also had >> success naively providing implementations of the missing functions in >> file pthread_scheduler.c >> >> >> >> Warm regards, >> >> Noah >> >> >> _______________________________________________ >> pocl-devel mailing list >> poc...@li... >> https://lists.sourceforge.net/lists/listinfo/pocl-devel > > _______________________________________________ > pocl-devel mailing list > poc...@li... > https://lists.sourceforge.net/lists/listinfo/pocl-devel |
From: Isuru F. <is...@gm...> - 2022-05-20 14:51:10
|
I think the issue is that you don't have the conda environment activated. Activating the conda environment sets the SDKROOT env variable so that clang can find the macOS SDK. I maintain the pocl conda package with some other maintainers. You can find our build scripts at https://github.com/conda-forge/pocl-feedstock/blob/main/recipe/build.sh Isuru On Fri, May 20, 2022 at 9:38 AM Noah Reddell <noa...@gm...> wrote: > Hi, > I upgraded to an M1 Pro Mac and found that MacOS's built-in OpenCL > implementation no longer supports the CPU device. The GPU is > supported -- for now at least, but doesn't do fp64. > I'm very motivated to have a local OpenCL platform on my Mac that > supports CPU device. This is by far the most productive way for me to > first debug and develop kernels versus GPU-based debugging or on > remote systems. So I return to POCL but for the first time trying to > use it on a Mac. I'm having struggles. (latest releases MacOS > 12.3.1, XCode 13.4) > > My problems trying to build and run the latest POCL are more complex, > so I'll first mention a problem trying to use POCL acquired with the > Conda package manager this week. I can build and run a simple > hello-world program with one kernel and it computes the right answers > using POCL. > OpenCL Devices Detected: > Platform: Portable Computing Language > Type: CPU, Name: pthread > > > Unfortunately, when I run my large computational science application, > I get a runtime error shortly after the first call to > clEnqueueNDRangeKernel(). The function returns CL_SUCCESS, another > thread raises SIGABRT, I assume after the following output: > > ld: dynamic main executables must link with libSystem.dylib for > architecture arm64 > error: linker command failed with exit code 1 (use -v to see invocation) > Final linking of kernel physical_initial_condition_evaluation failed. > > Since my hello-world app works, yet the app I care about doesn't, my > leading suspicion so far is some confusion about which clang / llvm is > getting utilized. I've tried to be careful about what PATH is set and > I'm not setting DYLD_LIBRARY_PATH in any way. > I'd love to pass "-v" to the POCL link as suggested, but I'm not sure > how to do that. > The main application *is* linked with -lSystem so that error message > is probably referring to the POCL kernel build. > It looks like POCL_MSG_PRINT_LLVM could be helpful, but I think that > is only set when POCL is built, and I'm not able to build. > > Ok, so any suggestions about the above problem would be appreciated! > > > Sometime I'd really like to be able to build POCL myself. > > I can tell that some special steps are needed to get the latest POCL > to build for MacOS. Who is maintaining that Conda package? Are the > build steps available? > > Lesser question stemming from my failed attempts to build POCL from > source: > Question: What is the difference between the "basic" device and > "pthread" device? I'm not finding documentation for either host > devices. > One reason I ask is that I found problems building "pthread" due to > Apple's pthread.h not including pthread_barrier support. Looks > like two lines in CMakeLists.txt under if(ENABLE_HOST_CPU_DEVICES) > could be modified to turn off the pthreads device. I also had > success naively providing implementations of the missing functions in > file pthread_scheduler.c > > > > Warm regards, > > Noah > > > _______________________________________________ > pocl-devel mailing list > poc...@li... > https://lists.sourceforge.net/lists/listinfo/pocl-devel > |
From: Noah R. <noa...@gm...> - 2022-05-20 14:38:06
|
Hi, I upgraded to an M1 Pro Mac and found that MacOS's built-in OpenCL implementation no longer supports the CPU device. The GPU is supported -- for now at least, but doesn't do fp64. I'm very motivated to have a local OpenCL platform on my Mac that supports CPU device. This is by far the most productive way for me to first debug and develop kernels versus GPU-based debugging or on remote systems. So I return to POCL but for the first time trying to use it on a Mac. I'm having struggles. (latest releases MacOS 12.3.1, XCode 13.4) My problems trying to build and run the latest POCL are more complex, so I'll first mention a problem trying to use POCL acquired with the Conda package manager this week. I can build and run a simple hello-world program with one kernel and it computes the right answers using POCL. OpenCL Devices Detected: Platform: Portable Computing Language Type: CPU, Name: pthread Unfortunately, when I run my large computational science application, I get a runtime error shortly after the first call to clEnqueueNDRangeKernel(). The function returns CL_SUCCESS, another thread raises SIGABRT, I assume after the following output: ld: dynamic main executables must link with libSystem.dylib for architecture arm64 error: linker command failed with exit code 1 (use -v to see invocation) Final linking of kernel physical_initial_condition_evaluation failed. Since my hello-world app works, yet the app I care about doesn't, my leading suspicion so far is some confusion about which clang / llvm is getting utilized. I've tried to be careful about what PATH is set and I'm not setting DYLD_LIBRARY_PATH in any way. I'd love to pass "-v" to the POCL link as suggested, but I'm not sure how to do that. The main application *is* linked with -lSystem so that error message is probably referring to the POCL kernel build. It looks like POCL_MSG_PRINT_LLVM could be helpful, but I think that is only set when POCL is built, and I'm not able to build. Ok, so any suggestions about the above problem would be appreciated! Sometime I'd really like to be able to build POCL myself. I can tell that some special steps are needed to get the latest POCL to build for MacOS. Who is maintaining that Conda package? Are the build steps available? Lesser question stemming from my failed attempts to build POCL from source: Question: What is the difference between the "basic" device and "pthread" device? I'm not finding documentation for either host devices. One reason I ask is that I found problems building "pthread" due to Apple's pthread.h not including pthread_barrier support. Looks like two lines in CMakeLists.txt under if(ENABLE_HOST_CPU_DEVICES) could be modified to turn off the pthreads device. I also had success naively providing implementations of the missing functions in file pthread_scheduler.c Warm regards, Noah |