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

Re: AMD ROCm packaging session followup notes

Hi Cory,

Cordell Bloor, on 2021-11-25:
> Great summary, Étienne.
> > Thanks Cordell for your time, don't hesitate to complement or
> > correct me;
> Thank you for taking the meeting. The time was arranged to be convenient for
> Japan and Canada, so it was rather extraordinary that you came from Europe.

Yes, I initially thought I would just pop up to get myself
finally started on that front.  I probably won't do many more
meetings that late on my end for the same reason as Gard; the
week has been… complicated.

> Your English is also a lot better than my French. Je allé à l'école
> française, mais je oublie beaucoup.

You're welcome, but I cheat, I have some ten years of dayjob
with daily english practice.  Vous vous en sortez bien malgré le
manque de pratique.  ;)

> Upon closer inspection, I see that you wanted me to compl/e/ment you. I
> suppose I can do that too.
> >      I think one source of
> >      confusion is that there seem to be distinct Github teams
> >      involved in the various ROCm components.  I gathered some
> >      components on RadeonOpenCompute [1], and some other such as
> >      the HIP compiler in ROCm-Developer-Tools [2].  There might
> >      be other locations, I didn't manage to locate rocclr for
> >      instance.
> > 
> >      [1]: https://github.com/RadeonOpenCompute/
> >      [2]: https://github.com/ROCm-Developer-Tools/
> There is also https://github.com/ROCmSoftwarePlatform/
> Generally speaking, the lowest-level components are found under
> RadeonOpenCompute, the middle-of-the-stack components are found under
> ROCm-Developer-Tools and the high-level libraries and frameworks are found
> under ROCmSoftwarePlatform.

Ah, amazing, thanks for the location of the last item and the
clarification about the different levels of software!

> > I didn't manage to locate rocclr for instance.
> https://github.com/ROCm-Developer-Tools/ROCclr

Ah, thanks!  It seems like I didn't look well enough.

> >   Q: In which order to build the different components?
> > 
> >   A: This is still not entirely clear, but trying to package
> >      targets will eventualy reveal dependency trees (hopefully
> >      without loops involved).
> There won't be any loops involved.
> It's not a minimal dependency tree, but I've attached a file with the
> tarball URLs, build commands and packages that I used to build the first few
> components (up to and including comgr) on the Debian unstable docker image.
> I didn't isolate the packages from each other as I was building them, so
> anything installed in an earlier stage _could_ be a dependency for a later
> stage (but few actually are).
> Going through the file from top to bottom defines one possible (serialized)
> build order. Attempting each step in an isolated environment would quickly
> lead you to the actual minimal tree.

Many Thanks Cory!  Each source tarball can eventually be handled
more or less independently (assuming dependencies are available
of course).  On Debian side, repositories are available on
Salsa [1].  Not every packaging project has a debian/watch file
yet for monitoring latest upstream version, but thanks to the
tarball location you provided, this can be completed.

[1]: https://salsa.debian.org/rocm-team/

I see if I can pick a package at random and get somewhere with
an upgrade to the ROCm 4.5 version, and why not, attempt to see
how things go with Debian native llvm.

> Sincerely,
> Cory Bloor

Have a nice day,  :)
Étienne Mollier <emollier@emlwks999.eu>
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/1, please excuse my verbosity.

Attachment: signature.asc
Description: PGP signature

Reply to: