# \[ROCm, HIP\] architecture detection: keep track of failed command execution
**URL:** https://discourse.cmake.org/t/rocm-hip-architecture-detection-keep-track-of-failed-command-execution/9146
**Category:** Development
**Created:** [October 5, 2023, 5:02pm UTC](https://discourse.cmake.org/t/rocm-hip-architecture-detection-keep-track-of-failed-command-execution/9146 "2023-10-05T17:02:14Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@Matteo\_Concas](https://discourse.cmake.org/u/Matteo_Concas)
#### Post date: [October 5, 2023, 5:02pm UTC](https://discourse.cmake.org/t/rocm-hip-architecture-detection-keep-track-of-failed-command-execution/9146/1 "2023-10-05T17:02:14Z")
When using ROCm, GPU architecture detection is steered by using
`rocm_agent_enumerator` executable.
It can happen that during a project configuration stage the call to the
executable fails, e.g. because of a different Python version picked up
at configuration stage w.r.t. the system one that is working.
In this case it happens that the detection selects a default
architecture and goes forward. The logic to get default architecture is
not clear to me, but it does not really matter at this point.
I might have a limited understanding of the context but I wonder if it
couldn’t make much sense to propagate the result of this (auto)detection
failure/default pick inside a dedicated variable.
In this way cmake would leave some flag to the project maintainers to
override the default choice.
This would be useful especially because errors due to targets built
against the wrong GPU architectures can be spotted only later during
program execution.
---
### Author:  [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [October 6, 2023, 2:31pm UTC](https://discourse.cmake.org/t/rocm-hip-architecture-detection-keep-track-of-failed-command-execution/9146/2 "2023-10-06T14:31:40Z")
For CUDA we detect what `nvcc` selects as its default architecture and use that as the default value for `CMAKE_CUDA_ARCHITECTURES`. We also detect the host GPU’s native architectures, but we only use them if the user or project explicitly sets `CMAKE_CUDA_ARCHITECTURES` to `native`. If `native` is requested but no native architectures were detected, we issue a cmake-time error.
In order to use a similar approach for ROCm+HIP we need a way to choose default `CMAKE_HIP_ARCHITECTURES` that does not rely on native hardware detection. Does anyone know if/how `hipcc` and/or ROCm’s `clang` selects a default AMD GPU architecture if no explicit `--offload-arch=` is given?
---
### Author:  [@mconcas](https://discourse.cmake.org/u/mconcas)
#### Post date: [October 7, 2023, 3:35pm UTC](https://discourse.cmake.org/t/rocm-hip-architecture-detection-keep-track-of-failed-command-execution/9146/3 "2023-10-07T15:35:17Z")
> Does anyone know if/how `hipcc` and/or ROCm’s `clang` selects a default AMD GPU architecture if no explicit `--offload-arch=` is given?
Looking at the `hipcc.pl` [script](https://github.com/ROCm-Developer-Tools/HIPCC/blob/0c6fa324b1e5e01f72f972cdfd1df610d3c7f53b/bin/hipcc.pl#L491), the logic to detect available architectures is via `rocm_agent_enumerator`, which is the same approach in use by CMake.
The question might be how the default architecture is chosen in CMake if the enumerator does not work.
E.g. see: [here](https://gitlab.kitware.com/cmake/cmake/-/blob/v3.27.6/Modules/CMakeDetermineHIPCompiler.cmake?ref_type=tags#L221).
Regardless, having a state reporting the failed autodetection would help to externally manage these cases.
---
### Author:  [@brad.king](https://discourse.cmake.org/u/brad.king)
#### Post date: [October 11, 2023, 2:06pm UTC](https://discourse.cmake.org/t/rocm-hip-architecture-detection-keep-track-of-failed-command-execution/9146/4 "2023-10-11T14:06:09Z")
I’ve opened [CMake Issue 25325](https://gitlab.kitware.com/cmake/cmake/-/issues/25325) for this, thanks.