HIP-CPU
HIP-CPU copied to clipboard
ROCm
Provide FindHIP.cmake, HIPConfig.cmake, hip-config.cmake to aid building other HIP Libraries
HIP-CPU supplies
./share/hip_cpu_rt/cmake/hip_cpu_rtConfig.cmake
./share/hip_cpu_rt/cmake/hip_cpu_rtTargets.cmake
./share/hip_cpu_rt/cmake/hip_cpu_rtConfigVersion.cmake
but some ecosystem libraries (e.g. hipCUB) look for FindHIP.cmake, HIPConfig.cmake or hip-config.cmake. Can one do a direct symlink of e.g. hip_cpu_rtConfig.cmake to hip-config.cmake to help build these libraries, or can an appropriate FindHIP/HIPConfig/hip-config.cmake be provided?
Hello, thank you for opening this, it's an interesting topic. Whilst the usability benefits are clear, I'm not sure about the costs in this particular instance / what the best way to go about this would be. Let's consider https://github.com/ROCm-Developer-Tools/HIP/blob/main/cmake/FindHIP.cmake. That's pretty thermonuclear and highly opinionated in many regards, and it defines quite a few interface components which are very tightly tied to only work with ROCm and its current deployment. A straight symlink won't work, unfortunately.
Furthermore, peeking at what hipCUB does, it actually uses https://github.com/RadeonOpenCompute/rocm-cmake, which is OK if you happen to have ROCm, but definitely won't quite do what we want in general. It also has its own expectations regarding how a HIP implementation is supposed to quack in order to be a valid duck.
Understood. I think the bigger point would be ecosystem support in general. I think HIP-CPU would have great utility as a debugging tool and as a potential solution for CI on public CI systems like Travis/GitHub/GitLab/Jenkins etc. but this would be difficult for projects which use the ecosystem components. I myself am working on a project that uses hipCUB/rocPRIM, hipBLAS/rocBLAS, hipFFT/rocFFT and hipRAND/rocRAND.
I wonder if it'd not be more ecumenical if we tried to work with the maintainers of said projects to merely add HIP-CPU to their build infrastructure, since it's quite straightforward to do, and it just composes with CMake. At least as a medium-term solution, unification is somewhere in the future, and it'll remove the hassle. For what it's worth, rocRAND and rocFFT were actually part of the bring-up, and it was not too onerous to wire HIP-CPU in.
That sounds like a reasonable plan. Let me see if I can dig about and find out how hard converting/converging some of these projects may be. Sounds from what you wrote that rocRAND and rocFFT may be easy? Let me have a look at hipCUB/hipBLAS. It loooks like hipCUB and ROCPrim may be mostly headers? Perhaps if adopting HIP-CPU is straightforward for these it may be possible to submit PRs to the other projects.
-- Balint Joo, Oak Ridge Leadership Computing Facility, Oak Ridge National Laboratory P.O. Box 2008, 1 Bethel Valley Road, Oak Ridge, TN 37831, USA email: joob AT ornl.gov. Tel: +1-757-912-0566 (cell, remote)
From: Alex Voicu [email protected] Reply-To: ROCm-Developer-Tools/HIP-CPU [email protected] Date: Wednesday, January 6, 2021 at 10:14 AM To: ROCm-Developer-Tools/HIP-CPU [email protected] Cc: Balint Joo [email protected], Author [email protected] Subject: [EXTERNAL] Re: [ROCm-Developer-Tools/HIP-CPU] Provide FindHIP.cmake, HIPConfig.cmake, hip-config.cmake to aid building other HIP Libraries (#7) Resent-From: [email protected] Resent-Date: Wednesday, January 6, 2021 at 10:14 AM
I wonder if it'd not be more ecumenical if we tried to work with the maintainers of said projects to merely add HIP-CPU to their build infrastructure, since it's quite straightforward to do, and it just composes with CMake. At least as a medium-term solution, unification is somewhere in the future, and it'll remove the hassle. For what it's worth, rocRAND and rocFFT were actually part of the bring-up, and it was not too onerous to wire HIP-CPU in.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ROCm-2DDeveloper-2DTools_HIP-2DCPU_issues_7-23issuecomment-2D755357462&d=DwMCaQ&c=CJqEzB1piLOyyvZjb8YUQw&r=WG01dcOd8ZFLFFNkrpbj6A&m=4xsvk6smdh8VQYD6DA6ypWhLd7DKLsrAGLxtwfYY0M4&s=PvXgaDUMWotnJWUDIednGcXh93feebcDmlWks80YWO0&e=, or unsubscribehttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AAEPL2BS6NIRY5UUZLVKFX3SYR44ZANCNFSM4VWLZRKQ&d=DwMCaQ&c=CJqEzB1piLOyyvZjb8YUQw&r=WG01dcOd8ZFLFFNkrpbj6A&m=4xsvk6smdh8VQYD6DA6ypWhLd7DKLsrAGLxtwfYY0M4&s=fyyu6y_Cv-eECww86002Ev3es3jwtSDdBPcsbQtP-J0&e=.
it actually uses https://github.com/RadeonOpenCompute/rocm-cmake, which is OK if you happen to have ROCm
Rocm-cmake doesnt require rocm(and is tested on windows and mac which dont have rocm). Its just used to automate the generation of installation, packages, and usage requirements so it can be more uniform across our stack.
@bjoo, right rocRAND was very straightforward, rocFFT a bit less so. Note that I'm assessing ease here in terms of "what did it take to get CMake behaving correctly". IMHO the tidiest way to deal with this for the time being would be to merely have a CMake flag that controls whether you want HIP-CPU or HIP-CPU, and either do find_package(hip_cpu_rt...) + its inclusion ritual or go down the current path. So this'd be an addition to said projects' CMake infrastructure, albeit I'm certain I'm making it sound far simpler than it is:)
IMHO the tidiest way to deal with this for the time being would be to merely have a CMake flag that controls whether you want HIP-CPU
That is exactly what I did in one such project and it isn't all that difficult (depending on the structure of the project at hand). I for one can tell rocPRIM is on it's way to receiving similar treatment. (Which in turn opens the way for rocThrust, etc.) Do note that these libs often rely on compiler built-ins (warp_move_dpp for eg.), so code modifications are also needed, not much, but enough to trigger some testing as well.
@bjoo Just a heads-up, the PR to get initial HIP-CPU support for rocPRIM is out. Having taken a closer look at some of the failures, the solution may be simpler than I had anticipated; it may just be that some of the built-ins I implemented are wrong and that's what messes up many of the algorithms.