pocl 3.0 (new formula)

[cho-m]

• Have you followed the guidelines for contributing?
• Have you ensured that your commits follow the commit style guide?
• Have you checked that there aren't other open pull requests for the same formula update/change?
• Have you built your formula locally with brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• Is your test running fine brew test <formula>, where <formula> is the name of the formula you're submitting?
• Does your build pass brew audit --strict <formula> (after doing brew install --build-from-source <formula>)? If this is a new formula, does it pass brew audit --new <formula>?

---

Experimenting with OpenCL formulae on Linux.

[cho-m]

Added both loader options: ocl-icd and opencl-icd-loader. Looking for feedback on which we want to use on Linux for libOpenCL.so.

Also can discuss other details on how we want to distribute OpenCL on Linux.

I am thinking that we can just leave the OpenCL runtime installation to user rather than requiring a dependency, but this means the dependents won't work out-of-the-box. However, it allows users to pick a hardware-specific runtime rather than having to install a common denominator like pocl. In many cases, a GPU runtime will be better like:

• Intel - https://github.com/intel/compute-runtime - Intel iGPUs from Broadwell onward
• AMD - https://github.com/RadeonOpenCompute/ROCm-OpenCL-Runtime - for Radeon
• Nvidia - proprietary/non-free.

[danielnachun]

Just so I understand the plan, opencl-headers will be used to provide the headers for OpenCL applications, and for testing either ocl-icd or opencl-icd-loader will be used to load the CPU-based pocl OpenCL implementation. Users will need to configure either ocl-icd or opencl-icd-loader to load their preferred OpenCL backend. So this means that ocl-icd or opencl-icd-loader and pocl will be test dependencies on Linux and Apple Silicon (once it becomes ephemeral).

I think we can provide both ocl-icd and opencl-icd-loader as options for users, but I think we should use opencl-icd-loader for testing because it seems to be more actively maintained.

@cho-m do you consider this blocked by the LLVM 14 upgrade or do you think we can ship these as-is? We have quite a few OpenCL formulae to fix on Linux I'd like to get this out soon.

[cho-m]

This won't fix ephemeral Apple Silicon as formulae need to directly link to Apple's OpenCL Framework. Based on information in PoCL, the Framework doesn't work with 3rd party ICD loaders http://portablecl.org/docs/html/using.html#using-pocl-on-macosx

Mainly looking for feedback for now before finalizing on approach so we don't have to backtrack/fixup later.

On Linux, some formulae may link to libOpenCL.so provided by the loader, which would make it a hard dependency. In many cases, it may just be easier to make ICD loader a hard dependency like Arch does, e.g. hashcat (https://archlinux.org/packages/community/x86_64/hashcat/) has dependency on ocl-icd. In this case, we probably want to settle on a since ICD loader and exclude the other one.

PoCL 3.0 is now out which supports LLVM 14, so I'll use that in next run.

[danielnachun]

This won't fix ephemeral Apple Silicon as formulae need to directly link to Apple's OpenCL Framework. Based on information in PoCL, the Framework doesn't work with 3rd party ICD loaders http://portablecl.org/docs/html/using.html#using-pocl-on-macosx

That's good to know. Hopefully Khronos or someone else will develop an OSS OpenCL wrapper for Metal similar to MoltenGL for OpenGL (though that is not OSS right now).

Mainly looking for feedback for now before finalizing on approach so we don't have to backtrack/fixup later.

On Linux, some formulae may link to libOpenCL.so provided by the loader, which would make it a hard dependency. In many cases, it may just be easier to make ICD loader a hard dependency like Arch does, e.g. hashcat (https://archlinux.org/packages/community/x86_64/hashcat/) has dependency on ocl-icd. In this case, we probably want to settle on a since ICD loader and exclude the other one.
PoCL 3.0 is now out which supports LLVM 14, so I'll use that in next run.

It sounds like making an ICD loader a hard dependency is the way to go then. Let's use opencl-icd-loader because it is more actively maintained and is developed by Khronos.

[cho-m]

I think new PoCL 3.0 doesn't build with opencl-icd-loader due to pocl/pocl@3ecda3b.

OCL_ICD_INCLUDE_DIRS only exists with ocl-icd as it looks for ocl_icd.h header from that implementation, which is generated by https://github.com/OCL-dev/ocl-icd/blob/v2.3.1/icd_generator.rb#L865.

[danielnachun]

In that case I guess the decision has been made for us. I think we should still package opencl-icd-loader so that if the maintenance of ocl-icd becomes unsatisfactory, we'd have opencl-icd-loader ready to use. Since there aren't that many OpenCL formulae, it wouldn't be hard to switch them over later if needed. But for now let's see if we can get a working stack with pocl and ocl-icd and just treat opencl-icd-loader as a standalone formula.

Aside from rebasing/updating, is everything else ready to go for the formulae themselves? If so I think we should be able to publish after another CI run.

[cho-m]

Aside from rebasing/updating, is everything else ready to go for the formulae themselves? If so I think we should be able to publish after another CI run.

Still need to write tests for opencl-icd-loader and pocl.

I've split off ocl-icd to separate PR #104619 as that is probably ready to review and also the reason the PR is showing audit failure. I removed conflicts_with and will probably use keg_only for opencl-icd-loader as it is easier to switch between alternatives this way (based on previous experiences with other migrations).

There is a minor question on whether etc is best location. The ICD files need to be updated by corresponding formulae since they contain Cellar path. I think this does happen right now when file is installed by cmake as opposed to etc.install, though I don't know if that is intended.

[danielnachun]

I think this PR may need to be merged before #104619 if we want to make pocl a dependency of ocl-icd (which I think we should do). Since pocl isn't compatible with opencl-icd-loader, it shouldn't be a dependency for that and we should just make opencl-icd-loader available as an alternative for users who are using other OpenCL backends.

[cho-m]

I think this PR may need to be merged before #104619 if we want to make pocl a dependency of ocl-icd (which I think we should do).

I don't think this is possible as it makes them depend on each other. pocl needs to find headers from ocl-icd to build with ICD support.

At best, we can add pocl as dependency to the OpenCL formulae that depend on ocl-icd.

[danielnachun]

Okay that makes sense, I didn't notice the build dependency. I think it's fine to add pocl as a Linux-only dependency to all OpenCL packages.

[cho-m]

Split out opencl-icd-loader commits into separate PR #106164 as it is causing some issues when testing at same time as pocl --> ocl-icd.

Will drop commits from this PR.

[danielnachun]

It looks like the pocl test fails on ARM. Maybe this needs to be x86 only?

[cho-m]

It looks like the pocl test fails on ARM. Maybe this needs to be x86 only?

Current failure is due to RPATH for libraries inside #{lib}/pocl. Using -DCMAKE_INSTALL_RPATH=#{lib};#{lib}/pocl should help (or maybe -DCMAKE_INSTALL_RPATH=@loader_path;@loader_path/.. on macOS)

❯ poclcc -l
LIST OF DEVICES:
0:
  Vendor:   ARM
    Name:   pthread
 Version:   OpenCL 3.0 PoCL HSTR: pthread-arm64-apple-macosx12.0.0-cyclone

However, fixing that leads to test failure from trying to use SSE2 rather than Cyclone:

Kernel library file /opt/homebrew/Cellar/pocl/3.0/lib/../share/pocl/kernel-arm64-apple-macosx12.0.0-sse2.bc doesn't exist.

[cho-m]

Looks like new error is due to KERNELLIB_HOST_CPU_VARIANTS=distro which is only supported on x86_64.

May need to check if this needs ENV.runtime_cpu_detection on x86_64 since distro is supposed to build for multiple AVX/SSE options.

---

EDIT: Need to check further, but I don't think we need ENV.runtime_cpu_detection as bytecode compilation is directly run through LLVM rather than compiler shims, so it doesn't cause issues with necessary -mcpu and related flags.

[cho-m]

Also may need to check if LLVM Cellar will cause any issues:

/opt/homebrew/Cellar/pocl/3.0/lib/libpocl.2.9.0.dylib
--> match '/opt/homebrew/Cellar/llvm/14.0.6_1/bin/clang' at offset 0x7b111

[danielnachun]

Great job digging into the symlinking issue and fixing the build on ARM. I think this is ready to go!

[BrewTestBot]

@danielnachun has triggered a merge.