[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ROCm 20211221 Packaging session notes and small update

On Mon, 2021-12-27 at 10:54 +0100, maxzor wrote:
> I gave a try at an initial packaging for hipamd, and managed to get
> the
> hipamd binaries produced. The package is in a very rough state,
> but functional (tests are disabled, they can be activated in
> debian/rules).
> https://salsa.debian.org/maxzor/rocm-hipamd
> Hopefully it can serve as a support to design this package better.
> I used the component feature of dpkg-source, to bundle the four git
> repos
> together.
> https://wiki.debian.org/Projects/DebSrc3.0#How_to_use_multiple_upstream_tarballs_in_3.0_.28quilt.29_format.3F
> hipamd now compiles (lintian yells everywhere) as the 8th source
> package
> in the little docker builder:
>  > https://salsa.debian.org/maxzor/rocm-builder

Thanks! please keep up your good work

> I have a few questions:
> - "-DCMAKE_HIP_ARCHITECTURES" is made mandatory by upstream cmake
>    in hipamd CMakeLists.txt. What to do? Patch out the flag,
>    make a general package... or make a package per target GPU?
>    (debian/rules go gfx906 here)

I'm not sure whether the HIP compiler can compile the code for
different architectures into a single binary like NVCC from CUDA
toolkit. If that's the case, the recommended choice is to enable
as much GPU architectures as possible (because we don't know
what GPU a random Debian user will use). GPU architectures with
buggy support can be filtered out temporarily, though.
This is eventually up to the package maintainer.

As for "a package per target GPU", my anticipation is that it will
lead to unnecessary maintainance burden. Just putting all
in one package is fine. 

> - how to name source and binary packages?
>    See the AMD-Debian mapping table in the builder README.

Ummm ... do you mean this README?

Generally if the upstream package name is unique enough, we
just follow the upstream for the source package name.
For library packages, that roct-thunk-interface is an example,
it follows the upstream for source package, and its binary
packages follows the resulting shared objects.

> - where to install the files, as already discussed?
>    I have started a csv with the layout that I went with here.
> https://salsa.debian.org/maxzor/rocm-builder/-/blob/master/misc/wonders/amdhip_installs.csv
You may browse the file tree of other similar debian packages
for reference. Besides, you may also check your package with
lintian. If the install path is seriously wrong, lintian
will tell you through errors. We can start from this.

Reply to: