On 1/4/22 3:59 PM, Jon Chesterfield wrote:
> Hi Debian,
Hello Jon,
>
> I've been a user since Lenny and an llvm dev for a few years. Emailing this
> drivers/open-source-amd-linux/1296835-debian-is-packaging-rocm-help-them-out
> and discovering Gentoo/Arch have some packaging in place.
>
> I develop llvm trunk for amdgpu openmp, using Debian and rocr/roct/device-
> libs built from source, sometimes with Linux upstream and sometimes the
> rocm dkms module.
Great!
> I'd expect pain points to be the libraries that are distributed as bitcode
> (and thus need to broadly match the clang in use) and differences in behaviour
> between upstream and rocm kernel drivers.
I personally did not face much issue about these points, but it is probable
that I encountered them and that they flew over my head. I use 5.10+ kernels
and debian:testing(/sid)
> Possibly also the rocm cmake assumptions and use of runpath.
This is quite a pain point to me currently, I just reached from hipamd and up
this issue, which Cordell struggled with, and mentioned some time ago
already [1].
I just regressed the rocm-hipamd package to install in /usr/hip for now [2] ...
The next two paragraphs are FYI, you may already know most of it.
I'll try my best at a quick tour of the team (apologies to anyone forgotten):
- Norbert Preining is an expert Debian Maintainer.
- Mo Zhou is an experienced Debian Maintainer currently studying in Harvard.
- Cordell Bloor is a colleague of yours, he probably does not need introduc-
tion :) He has mostly taken the lead and driven progress last months, with
Etienne coming in clutch.
- Etienne Mollier is a Debian Maintainer strongly involved in the Debian
medical and science packages.
- I am the one who wrote the post that you linked, and am nearing what
I believe is called a sponsored Debian Maintainer.
As for resources, Etienne is in a better place to give you hints at Debian
documentation (debian policy, debian developer's guide, packaging tooling...),
meanwhile there is the archive of the mailing list browsable here [3].
There was activity for the most part in May and November/December.
> What can I do to help / where is your packaging/patching effort organized?
I can't say for sure but, until now people seem to have been working on ROCm
packaging mostly sequentially: Norbert Preining started the initial packaging
work for the beginning of the stack a few years ago back at ROCm 2/3, Mo Zhou
continued a year ago. Cordell Bloor rallied the team in May and triggered very
informative discussions, alongside Etienne Mollier, which took the reins in the
packaging work and supervision. I reached out to the team a few weeks ago.
Having several people working at the same time on packaging would be some
first-world problem, which is not bad.
How do people do project management these days?
Is Trello acceptable? Hopefully not reinventing any battle-tested Debian wheel,
I tried to make a stub of a board [4] , there is detail in the cards.
I'd be quick to promote every participant as board admin if there is any
interest! We could maybe find a way to 'add ourselves' to the board tasks we
are tackling? I am not an expert at Atlassian :/
Waiting for input from others, from my point of view your knowledge could
surely be profited upon with you giving a hand at structuring documentation.
You could also for example write manpages about the llvm-related packages,
such as clr, comgr, hipamd? ROCt, ROCk, ROCr, device lib, smi...?
Depending if you are willing to dig into packaging groundwork, there is
surely work in this area also.
And more importantly brainstorming on the pending design decisions?
Helping produce tests/benchmarks from the packages and debug discrepancies,
input compiler secret knobs...?
Personally, while not qualified to make the design decisions mentioned in the
trello board and that I exposed here [5], I self-assigned the task of producing
an initial package for user-facing libraries this week: rocSOLVER, hipFFT,
and pushing them to the team repos [6] .... These early packages are quite in
the same state of refinement as the deb packages produced directly by AMD.
They do compile with vanilla LLVM, I am not using AMD LLVM package.
I chose to follow the install directories of Cordell's script [7], which worked
easily, for now, since they do comply with cmake assumptions. I can obviously
adapt, as we rearrange targets! I will have less time during next weeks.
I also made two builders if they can be of any use (they are quite dumb),
one for debian packaging [8], the other for unbundling amd-llvm [9].
> Thanks!
>
> Jon
Welcome and thank you for chiming in!
Best regards, Maxime