Hi Samuel,
Ah, it's not backward-compatible?
That is correct. When you build your HIP language binaries, the
device code is built for the native AMD GPU machine code. There's
no guarantee of machine code compatibility even within a
generation of GPUs, let alone from one generation to the next.
There is some experimental work to support targeting an intermediate representation (SPIR-V) and JIT to native machine code, but it's not ready for adoption in Debian yet. There are also "generic" architecture targets that are essentially the lowest-common denominator of instructions that will run on a generation of GPUs. I expect Debian will probably adopt the generic architecture targets later this year.
It would be convenient that rocm-target-arch provides a way to produce the --offload-arch series, to save all maintainers from coining some debian/rules snippet for that 🙂
This was needed because starpu is the first autotools-based project I've encountered using the HIP language. It's a bit more straightforward for CMake projects, as that's a more well-worn path. The feedback, however, is well-taken.
(similarly to dpkg .mk files which provide CC, CFLAGS, etc. we could have HIPCCFLAGS)
I opened a bug on dpkg-dev a while ago to provide HIPFLAGS [1],
but we need to get that over the finish line. The HIPFLAGS should
be the same as the CXXFLAGS, but in cases where the CXXFLAG is
incompatible with HIP, it needs to be dropped or filtered to only
be applied to the host. The d/rules for src:rocrand as a good
example [2][3]. I didn't really understand the discussion on the
bug, so I would appreciate some help with getting that over the
finish line.
Sincerely,
Cory Bloor
[1]: https://bugs.debian.org/1065439
[2]:
https://salsa.debian.org/rocm-team/rocrand/-/blob/debian/6.4.1-1_exp1/debian/rules?ref_type=tags#L3
[3]:
https://salsa.debian.org/rocm-team/rocrand/-/blob/debian/6.4.1-1_exp1/debian/rules?ref_type=tags#L8-10