Hi all,
before I get into details, I'd like to propose that a policy document be
created that documents at least the following:
1. Supported architecture lists
2. Updating the ROCm stack (experimental, unstable, Ubuntu)
3. Triggering/shipping changes to the supported architecture list
4. QA thresholds
I think this would
* Clarify for users what they can expect
* Simplify regular updates
* make it simpler to reason about larger changes
Thoughts?
On 2026-07-01 10:30, Talha Can Havadar wrote:
> We do have a dependency group list for the packages we were working on
> Ubuntu. Please see below for the list.
I found this list *very* useful - thanks!
> I would suggest us to define the target architectures and start with
> pkg-rocm-tools in unstable then migrate packages from experimental
> following the order.
Just to have had discussed it: an alternative would be to update
pkg-rocm-tools last. In other words, get the full ROCm stack working in
unstable with the currenty supported list, then update pkg-rocm-tools,
then do a binNMU.
Both approaches have different failure modes/problem scenarios.
I would slightly lean towards pkg-rocm-tools last, because it isolates
supported architecture list issues. As opposed to eg:
1. Updating group 1-3
2. Updating group 4, discovering that rocblas doesn't work with the
current list, possibly having to roll back some changes from 1.
Whereas doing pkg-rocm-tools last means that we can locally test new
architecture lists, as pass/fail, with rebuilds of all groups.
OTOH, I'm sure you've all gotten enough experience with the stack and
the supported architectures in the Ubuntu updates, so the above might be
too cautious of an approach.
> We have proper build-depends restrictions for the packages on
> version 7.2.4 targeting at least >= 7.2.0~ but I am not sure how
> debian build environment handles dependency waits if it will queue
> properly we can also just migrate all.
Builds wait indefinitely until build dependencies are available.
Best,
Christian
> Group 1 (9 packages) [contains CYCLIC dependencies]:
> Regular packages:
> amdsmi, hipify, pkg-rocm-tools, rocm, rocm-cmake, rocm-core,
> rocm-smi-lib
> Cyclic packages (require bootstrapping):
> rocm-llvm -> depends on: rocr-runtime
> rocr-runtime -> depends on: rocm-llvm
>
> Group 2 (5 packages):
> hipblas-common, rocalution, rocdbgapi, rocm-hipamd, rocminfo
>
> Group 3 (5 packages):
> rccl, rocprim, rocrand, roctracer, ucx
>
> Group 4 (6 packages):
> composable-kernel, hipcub, hiprand, rocblas, rocsparse, rocthrust
>
> Group 5 (5 packages):
> hipblaslt, hipsparse, rocfft, rocsolver, rocwmma
>
> Group 6 (4 packages):
> hipblas, hipfft, hipsolver, hipsparselt
>
> Group 7 (2 packages):
> ggml, miopen
>
> Group 8 (2 packages):
> llama.cpp, pytorch-rocm
>
> Best regards,
> Talha
>
> On Mon, Jun 29, 2026 at 10:18:50AM +0200, Christian BAYLE wrote:
>> Hello all,
>>
>> Le 28/06/2026 à 23:16, Christian Kastner a écrit :
>>> Hi,
>>>
>>> first, thank you all at Canonical, AMD, and Christian Bayle for getting
>>> our ROCm stack updated to 7.2!
>>>
>>> The update looks mostly complete. Is there a strategy for how to proceed
>>> next? In particular:
>>>
>> I was asking myself the same questions
>> According to https://rocm-team.pages.debian.net/index-large.html
>> I think there is some work ongoing on miopen, also missing hipsparselt,
>> If I can help, let me know.
>>
>>> (1) Which tests should our CI run in experimental?
>>>
>> As much as possible ;-), not sure all the profiles are ok, and it would also
>> be great to have some specific runners to be able to execute build and
>> profiles tests on salsa.
>>
>>> (2) When uploading to unstable, in what order should this happen?
>>> Libraries first, or lower parts of the stack first? Again,
>>> something that our CI should test.
>>
>> I made some build experiment on therock that give an order, and AFAIK, there
>> is a set of group in ubuntu to give the order
>>
>>>
>>> (3) How do we deal with new architectures in pkg-rocm-tools, which
>>> are still only active in experimental?
>>>
>> Don't know, and I must admit i'm not at all aware of the transitions things
>> in debian, binnmu and so on.
>>
>>> Since everything in experimental seems to have built fine, does
>>> this imply that the current list is safe, or do we need to cull
>>> some architectures? See also [1]
>>>
>> For arch, i wonder what's to be done and how it's planned to evolve
>> I therock there are separate / incompatible build for
>>
>> THEROCK_AMDGPU_FAMILIES="dcgpu-all"
>> THEROCK_AMDGPU_FAMILIES="igpu-all"
>> THEROCK_AMDGPU_FAMILIES="dgpu-all"
>>
>> There is some code that handle this here:
>> https://github.com/ROCm/TheRock/blob/main/build_tools/_therock_utils/cmake_amdgpu_targets.py
>>
>>
>> Not sure this fits our needs, but you may be interested by how it's done
>>
>>> What other things might need to be considered?
>>>
>> Some automation of the transition process would be great, maybe using your
>> ppa setup, to run the tests ?
>>
>>> Best,
>>> Christian
>>
>> The following list also gives some information about build time
>> this is done with a very simple
>>
>> cmake -B build -GNinja \
>> -DCMAKE_BUILD_TYPE=Release \
>> -DTHEROCK_VERBOSE=ON \
>> -DTHEROCK_ENABLE_ALL=ON \
>> -DTHEROCK_AMDGPU_FAMILIES=$THEROCK_AMDGPU_FAMILIES \
>> -DTHEROCK_BUNDLE_3RDPARTY=OFF \
>> -DTHEROCK_BUNDLE_SYSDEPS=OFF \
>> -DTHEROCK_BUNDLE_EXTERNAL=OFF \
>> -DCMAKE_C_COMPILER_LAUNCHER=ccache \
>> -DCMAKE_CXX_COMPILER_LAUNCHER=ccache \
>> .
>>
>>
>> and some patch to disable as much as possible 3rdparty builds
>>
>>
>> [1]
>> [rocm-cmake SUCCEEDED in 0 seconds]
>> [rocprof-trace-decoder SUCCEEDED in 0 seconds]
>> [rocm-kpack SUCCEEDED in 0 seconds]
>> [therock-aux-overlay SUCCEEDED in 0 seconds]
>> [ocl-icd SUCCEEDED in 0 seconds]
>> [rocm_smi_lib SUCCEEDED in 0 seconds]
>> [rocm-half SUCCEEDED in 0 seconds]
>> [rocm-core SUCCEEDED in 0 seconds]
>> [rocprofiler-register SUCCEEDED in 0 seconds]
>> [amd-llvm SUCCEEDED in 390 seconds]
>> [hipcc SUCCEEDED in 0 seconds]
>> [amd-comgr SUCCEEDED in 6 seconds]
>> [amd-dbgapi SUCCEEDED in 9 seconds]
>> [rocgdb SUCCEEDED in 502 seconds]
>> [ROCR-Runtime SUCCEEDED in 30 seconds]
>> [rocminfo SUCCEEDED in 1 seconds]
>> [hipify SUCCEEDED in 39 seconds]
>> [amdsmi SUCCEEDED in 51 seconds]
>> [hip-clr SUCCEEDED in 17 seconds]
>> [ocl-clr SUCCEEDED in 20 seconds]
>> [hipBLAS-common SUCCEEDED in 0 seconds]
>> [mxDataGenerator SUCCEEDED in 0 seconds]
>> [rocrtst SUCCEEDED in 7 seconds]
>> [roctracer SUCCEEDED in 156 seconds]
>> [aqlprofile SUCCEEDED in 155 seconds]
>> [rocPRIM SUCCEEDED in 0 seconds]
>> [rocr-debug-agent SUCCEEDED in 32 seconds]
>> [rocr-debug-agent-tests SUCCEEDED in 457 seconds]
>> [hipDNN SUCCEEDED in 599 seconds]
>> [libhipcxx SUCCEEDED in 659 seconds]
>> [rocprofiler-sdk SUCCEEDED in 1324 seconds]
>> [hipdnn_integration_tests SUCCEEDED in 992 seconds]
>> [rocprofiler-compute SUCCEEDED in 53 seconds]
>> [rdc SUCCEEDED in 107 seconds]
>> [hip-tests SUCCEEDED in 2401 seconds]
>> [rocRoller SUCCEEDED in 1154 seconds]
>> [rocshmem SUCCEEDED in 4124 seconds]
>> [rocRAND SUCCEEDED in 6259 seconds]
>> [hipRAND SUCCEEDED in 534 seconds]
>> [hipBLASLt SUCCEEDED in 8190 seconds]
>> [rccl SUCCEEDED in 13543 seconds]
>> [rocPRIM_tests SUCCEEDED in 20988 seconds]
>> [hipCUB SUCCEEDED in 20989 seconds]
>> [hipblasltprovider SUCCEEDED in 642 seconds]
>> [rocprofiler-systems SUCCEEDED in 21223 seconds]
>> [rccl-tests SUCCEEDED in 1981 seconds]
>> [rocThrust SUCCEEDED in 17884 seconds]
>> [rocBLAS SUCCEEDED in 16647 seconds]
>> [rocSPARSE SUCCEEDED in 4520 seconds]
>> [hipSPARSE SUCCEEDED in 118 seconds]
>> [hipSPARSELt SUCCEEDED in 151 seconds]
>> [rocWMMA SUCCEEDED in 9039 seconds]
>> [rocSOLVER SUCCEEDED in 27911 seconds]
>> [composable_kernel SUCCEEDED in 55081 seconds]
>> [rocFFT SUCCEEDED in 493962 seconds]
>>
>> it's the build for THEROCK_AMDGPU_FAMILIES="dgpu-all"
>>
>>
>> Regards
>>
>> Christian B.
>>
>