Menu
▾
▴
Re: [pocl-devel] MacOS and POCL challenges
|
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 >> > |