Re: ci.rocm: invalid device function
Hello,
Christian Kastner, le jeu. 24 juil. 2025 08:22:41 +0200, a ecrit:
> Your 1 LOC solution [2] is already so simple and concise that I
> whether adding logic for other approaches is worth the added interface
> complexity.
>
> The HIPCCFLAGS approach you suggest could work, but I don't know if
> setting that would clash with some other potential use, and maintainers
> still have to add 1 LOC.
This was the same with dpkg-buildtools.mk, and yet they defined it.
> Alternatively, rocm-target-arch could get gain another option for this
> particular output format.
Yes, that's what I was thinking about, not change the current output.
> Alternatively, the existing --sep option could infer/do this when use
> with some special value, eg: --sep=offload-arch. Though that might
> already be too clever?
At some points, there could also be some more options than just
offload-arch that we'd want to pass to hipcc, that e.g. disables some
GPU features that we know we don't want in Debian, or that we want in
Debian (e.g. hardening).
> PS: If you are using rocm-target-arch in a package build, please also
> use the --for-build option, which will pick the arch list for the
> distribution in d/changelog. experimental currently has more arches
> then unstable.
I was surprised by the option name. It resonates with build/host/target
triples, but apparently it has nothing to do with that? I'd advise
renaming it to avoid confusion.
With regards,
Samuel
Reply to: