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