Hi Jon, Jon Chesterfield, on 2022-01-04: > I've been a user since Lenny and an llvm dev for a few years. Emailing this > list after reading > https://www.phoronix.com/forums/forum/linux-graphics-x-org-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. > > 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. Possibly also the rocm > cmake assumptions and use of runpath. Good point, the llvm consistency issue has been mentionned once, but in private message unfortunately. I suspect postgresql-14 to have a similar issue, but there does not seem to be a classification per llvm/clang release: $ apt-file search bitcode […] postgresql-14: /usr/lib/postgresql/14/lib/bitcode/_int.index.bc […] postgresql-14: /usr/lib/postgresql/14/lib/bitcode/uuid-ossp/uuid-ossp.bc […] This issue seems mitigated by the fact that the postgresql-14 package depends on libllvm13, and no other major version. By using a similar approach, could it be a non-problem for ROCm device libs on Debian side after all? On the ROCk vs Linux amdgpu kernel driver side, this is a good point too. I believe the amdgpu version can condition the usable ROCm version, and at the time of the latest ROCm release, the Debian Linux amdgpu driver may be few steps behind the AMD ROCk driver. Heading to latest ROCm version may require waiting for ROCk amdgpu changes to make to the packaged Linux kernel. > What can I do to help / where is your packaging/patching effort organised? Thanks for jumping in! The packaging repositories are hidden below the rocm-team namespace on Salsa [1]. Let us know your account, so it can be added to the access list. You might be also interested in Debian Science packaging practices [2], from which the packaging of ROCm derives (note several fields, such as mailing lists, are adjusted to target debian-ai@l.d.o instead of debian-science). Also, you might find Mo Zhou's draft machine learning policy [3] to be appreciable food for thought. [1]: https://salsa.debian.org/rocm-team/ [2]: https://science-team.pages.debian.net/policy/ [3]: https://salsa.debian.org/deeplearning-team/ml-policy/-/blob/master/ML-Policy.pdf > Thanks! You're welcome, and thank you too for your interest! Have a nice day, :) -- Étienne Mollier <emollier@emlwks999.eu> Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/tty1, please excuse my verbosity. On air: Michael Hedges - Jitterboogie
Attachment:
signature.asc
Description: PGP signature