[ROCm] introduce HSARuntime_jll - #12672
Conversation
My eventual goal here is to ship the entire ROCm stack repackaged from ROCm nightlies. The HSA runtime is needed to determine the ROCm platform we should ship artifacts for. The next step would be to introduce a `rocm_sdk_core_jll` that uses platform augmentation based on this jll to select the right artifact, which I already have a proof of concept for locally.
and introduce a platform augmentation mechanism for the ROCm platform. Ref JuliaPackaging#12672
and introduce a platform augmentation mechanism for the ROCm platform. Ref JuliaPackaging#12672
and introduce a platform augmentation mechanism for the ROCm platform. Ref JuliaPackaging#12672
and introduce a platform augmentation mechanism for the ROCm platform. Ref JuliaPackaging#12672
and introduce a platform augmentation mechanism for the ROCm platform. Ref JuliaPackaging#12672
and introduce a platform augmentation mechanism for the ROCm platform. Ref JuliaPackaging#12672
and introduce a platform augmentation mechanism for the ROCm platform. Ref JuliaPackaging#12672
| ln -s librocprofiler-register.so.0 librocprofiler-register.so | ||
| """ | ||
|
|
||
| # ROCm only supports x86_64 Linux with glibc |
There was a problem hiding this comment.
The comment is a little misleading. Windows support should be fairly straightforward to add, only supporting Linux just seemed easier for this proof of concept
| @@ -0,0 +1,47 @@ | |||
| using BinaryBuilder, Pkg | |||
|
|
|||
| name = "HSARuntime" | |||
There was a problem hiding this comment.
Isn't this AMD or ROCm-specific? I.e., would a name like AMD_HSARuntime or ROCm_HSARuntime be more apt?
Cf. CUDA (JLL) package naming.
There was a problem hiding this comment.
The naming with AMD is a little bit of a mess, I think technically HSA might even be older than ROCm. I'm certainly open to changing the name though to be a little clearer
There was a problem hiding this comment.
At least, there is some AMD-specific stuff in there:
HSARuntime.v7.0.1120251130.x86_64-linux-gnu-cxx11/lib/rocm_sysdeps/lib/librocm_sysdeps_drm_amdgpu.so.1
HSARuntime.v7.0.1120251130.x86_64-linux-gnu-cxx11/lib/rocm_sysdeps/share/libdrm/amdgpu.ids
| using BinaryBuilder, Pkg | ||
|
|
||
| name = "HSARuntime" | ||
| version = v"7.0.01120251130" |
There was a problem hiding this comment.
What's the mapping from 7.11.0a20251130 to 7.0.01120251130?
There was a problem hiding this comment.
The versioning ROCm uses is quite weird, the official releases are 7 and 7.1, but the previews started at 7.9 and are now at 7.11. Not sure how to best map this versioning scheme to something semver-compatible
There was a problem hiding this comment.
OK, I was also wondering where the pip wheels stemmed from - are they from that "TheRock" thing? https://rocm.blogs.amd.com/software-tools-optimization/therock/README.html
There was a problem hiding this comment.
Yes, exactly! They have CI jobs producing those nightly wheels
| version = v"7.0.01120251130" | ||
|
|
||
| sources = [ | ||
| FileSource("https://rocm.nightlies.amd.com/v2/gfx1150/rocm_sdk_core-7.11.0a20251130-py3-none-linux_x86_64.whl", |
There was a problem hiding this comment.
Why use the nightlies? (I have no knowledge of ROCm releases/distribution, so just a basic overview of how ROCm stuff is released/distrbuted would be helpful)
There was a problem hiding this comment.
We should eventually switch to stable releases, it's just that I'm using gfx1150 locally for testing, which isn't supported by ROCm 7.1 yet
|
Decided to go with a slightly different approach in JuliaGPU/AMDGPU.jl#919 |
2 participants
My eventual goal here is to ship the entire ROCm stack repackaged from ROCm nightlies. The HSA runtime is needed to determine the ROCm platform we should ship artifacts for. The next step would be to introduce a
rocm_sdk_core_jllthat uses platform augmentation based on this jll to select the right artifact, which I already have a proof of concept for locally.