Jeremy Newton

Thanks for the patch. There's some interest from the distros to add support for non-x86 platforms, so I've rebased and squashed this for review internally. Edit: support as in code...

Hi @emollier, I have been working with @t-tye, and an engineer is currently working on fixing the installation path as @b-sumner mentioned. Once the patch has been pushed to amd-stg-open,...

@awehrfritz in the meantime, I've pushed a patch to the Fedora package: https://src.fedoraproject.org/rpms/rocm-compilersupport/c/88655a00df9719a91dca13e8e0a4dc3eb78ad073?branch=rawhide If that looks fine to you, I can cherry-pick it to Fedora 36 when I rebuild everything...

I made some changes to help unbundle the ICD loader via the option "BUILD_ICD", e.g. cmake -DBUILD_ICD=OFF. https://github.com/RadeonOpenCompute/ROCm-OpenCL-Runtime/pull/146/commits/e6ba9f6e613728621abe6cf3575d1bce92f620ae From this pull request: https://github.com/RadeonOpenCompute/ROCm-OpenCL-Runtime/pull/146 I'm not sure that openCL headers can...

This was merged internally, it should be mirrored here by rocm 5.7.

It looks like this was fixed in 6.2

I was speaking with some of the compiler guys and I believe the intention is to move towards using stable LLVM or at least allow for compilation against stable LLVM....

@searlmc1 as FYI > 4 of comgr test case use a feature to call amdgpu kernel within a amdgpu kernel, but the feature is not well implemented and not upstreamed....

Ok after some thought, for the meantime I think I'm going to try to maintain some branches for LLVM versions: https://github.com/Mystro256/ROCm-Device-Libs/tree/release/16.x https://github.com/Mystro256/ROCm-CompilerSupport/tree/release/16.x Feel free to contribute if you are interested....

The advantage of a dynamic library is that it doesn't required rebuilding dependent packages (i.e. ROCr in this case) if patches are manually cherry-picked in. It's not abnormal for distros...