#1087951 libhsa-runtime64-1: Assertion fails on gfx1033

Package:
libhsa-runtime64-1
Source:
libhsa-runtime64-1
Description:
HSA Runtime API and runtime for ROCm
Submitter:
Cordell Bloor
Date:
2025-08-15 10:43:02 UTC
Severity:
normal
Tags:
#1087951#5
Date:
2024-11-20 19:25:06 UTC
From:
To:
Dear Maintainer,

The libhsa-runtime64-1 library exits with an assertion on AMD Van Gogh hardware
(gfx1033). This is the GPU architecture of the Steam Deck, and the problem can
be observed on the Debian ROCm CI for essentially all tests involving the ROCm
software stack. The rocrand library is a good example [1]:

    [ RUN      ] rocrand_basic_tests/rocrand_basic_tests.rocrand_create_destroy_generator_test/1
    test_rocrand_basic: ./src/image/addrlib/src/gfx10/gfx10addrlib.cpp:1071: virtual rocr::Addr::ChipFamily rocr::Addr::V2::Gfx10Lib::HwlConvertChipFamily(unsigned int, unsigned int): Assertion `false' failed.
    Aborted

As a workaround, users can instruct the runtime to treat their GPU as if it were
Navi 21 by exporting the environment variable `HSA_OVERRIDE_GFX_VERSION=10.3.0`.

Sincerely,
Cory Bloor

[1]: https://ci.rocm.debian.net/packages/r/rocrand/unstable/amd64+gfx1033/42162/

#1087951#10
Date:
2024-11-21 02:15:17 UTC
From:
To:
Hi Cory,

So we should remove the assertion?

Best,
Xuanteng

#1087951#15
Date:
2024-11-21 02:15:17 UTC
From:
To:
Hi Cory,

So we should remove the assertion?

Best,
Xuanteng

#1087951#20
Date:
2024-11-21 17:46:07 UTC
From:
To:
Hi Xuanteng,

This is a regression from ROCm 5.2, which I'd tested manually some time
ago. This assertion did not used to trigger.

My suspicion is that the upstream developers added an assertion for
something that was never true (but they assumed was true without testing
on this hardware). On gfx1035, there was a similar problem where they
simply forgot to fill in one field with the hardware's minor version number.

It would _probably_ be fine to remove the assertion, but I suspect that
the problem that the assertion is checking for could probably be
trivially fixed by someone with more knowledge about the library than
myself. This bug needs to be forwarded upstream (along with the gfx1035
bug/patch, if it hasn't been fixed upstream already).

Sincerely,
Cory Bloor