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

Re: ROCm installation

On Wed, 2022-01-12 at 21:06 +0100, Maxime Chambonnet wrote:
> > Headers and libraries should installed under the standard path,
> > so that the compiler and linker should be able to find them without
> > additional flags. Just install all stuff to /usr should be enough.
> Currently for example rocm-hipamd installs to /usr/hip, and
> lintian yells a lot. All to /usr is quite not clear enough.

Then it sounds like that the upstream CMake installation targets
are primarily written for somewhere like /opt instead of /usr.
I looked into one Gentoo ebuild for ROCm and the problem is
rather distinct.


If shlibs are installed to somewhere like /usr/lib/rocm/lib/,
we are still able to tamper with ld.so.conf.
If binary executables are installed to /usr/lib/rocm/bin/,
then we are screwing up with the default shell PATH.
This is a deadend because we are not going to patch all
POSIX and non-POSIX shell configs. Neither do we introduce weird
scripts for the user to source.

Standarlizing the upstream install target is inevitable
to some extent.
A flag can be introduced for the upstream cmake file along
with some code, which by default install things to /usr/local
like most other existing software.

> > 
> > I did not understand this question. Do you mean something like
> > /usr/lib/rocm-{4.5.2,5.0.0},
> > or
> > /usr/lib/rocm-4.5.2/llvm ?
> Rather the first, not sure I see a difference, in all cases, it looks
> nested under "rocm-something" to me. And we further down agree
> that nested is probably not the way.

Yes. We should just stay away from nesting things.

> > How are these files read by ROCm? Is there anything like
> > "PYTHONPATH" for the gpu code files? We should choose a
> > supported path compatible to debian policy.
> There is a cmake flag / environment variable for now,
> The current preferred layout is /usr/amdgcn/*.bc

Anything like
/usr/share/amdgcn/ (in case they are arch-indep)
[/usr/lib/amdgcn, /var/lib/amdgcm, /var/cache/amdgcn]
(in ase they are arch-dep) could be better.

> > BTW, are these files architecture-independent? Namely,
> > can arm64 and amd64 produce the exactly the same (e.g.
> > md5sum-identical) output?
> I don't know, we discussed it last jitsi meeting and
> I believe that no one tried yet :)

Then we regard them as architecture-dependent for initial
debian packaging.

I looked around in the Gentoo ebuild repository,
from which we can borrow a lot. Namely, starting from
scratch by ourselves is not necessary.

Reply to: