Control: tags -1 - moreinfo Hi Paul,
On 2023-04-20 08:58, Paul Gevers wrote: > Sorry for taking so long to respond (the moreinfo tag was still attached > to the bug, so it didn't show up in my regular bts view, so please > remove it when you reply). done. > On 16-03-2023 11:40, Christian Kastner wrote: >>> Overall, the diff is a bit long (and has some irrelevant stuff), so >>> I'm hesitant to offer t-p-u now (to avoid waiting for >>> llvm-toolchain-15). >> >> Understood. Yeah, the diff is long, unfortunately, as the packaging >> fixes accumulated over time. > > That's why (especially around the freeze) we expect maintainers to keep > track of migration and ensure they happen. You got stuck behind > llvm-toolchain-15, but that's very unlikely to be fixed before the release. We were actually well aware of the migration issue (it was, after all, preventing our own migration). But that blocking RC bug appeared like an isolated issue in llvm-toolchain-15, so we were kind of speculating on the idea that it would eventually resolve itself in time. That bug got overlooked out of sheer bad luck, though. In the event that llvm-toolchain-15 will not be allowed to migrate: there are some fixes in the current version of rocm-hipamd that really should get into bookworm, most notably the missing libamd-comgr-dev dependency, and the added patches. The only way to do that with llvm-toolchain-15 from testing is by changing the dependency libclang-rt-15-dev back to libclang-common-15-dev (the pre-split version). If that is an option, I could prepare an upload, and also reduce out whatever other changes you don't feel comfortable with in the larger diff. >> Is this something that you could consider at a later point in time, if I >> also break down the diff into more reviewable fragments (dependencies, >> build, metadata, ...)? Because I do think that most changes are just >> fixes of one sort or another - no features added. > > I checked the diff again and I was about to propose to upload it to tpu, > but I saw the following: > > diff -Nru rocm-hipamd-5.2.3/debian/rules rocm-hipamd-5.2.3/debian/rules > --- rocm-hipamd-5.2.3/debian/rules 2022-10-20 19:20:33.000000000 +0000 > +++ rocm-hipamd-5.2.3/debian/rules 2023-03-10 22:38:51.000000000 +0000 > > [...] > + -DHIP_PLATFORM=amd > > Is that correct for the arm64 builds? Thanks for checking! Yes, that refers to the GPU arch, not the CPU arch. HIP code is portable in the sense that it can work with both AMD and Nvidia GPUs. Best, Christian
