Submission/spack blog

[garrettbyrd]

This blog outlines how to install ROCm + PyTorch using the Spack package manager. This is part of an effort to better provide resources for building the ROCm stack from source, since there are a number of open issues related to building from source. Authors are myself and @fluidnumerics-joe.

I've done my best to accommodate the metadata standards, but a review on these materials would be appreciated. If possible, AMD should provide a thumbnail to stay consistent with branding; else, I can provide one this week.

I have been in touch with AMD internal for this, let me know if anyone/who needs to be included in an email chain.

Related issues

The dependency matrix provided in this post should address Saad's issue regarding a ROCm dependency tree. I will be providing more context directly in that issue:

• Build a ROCm project dependency tree

I have opened a few issues directly related to some talking points in this blog. It may or may not be useful to address some of these before publication.

• What is rocm-utils?

• Inconsistent list of ROCm components across documentation

(I was going to mention this one as well, but Kent provided a very clear, very fast reply.)

Other relevant open issues

• Possiblity of providing the source code of libhsa-amd-aqlprofile64, or binary on other achitecture

• ROCm Linux packaging approaching bloatware: 29GB

PR Checklist

Signoff section must be completed prior to publishing.

• Technical reviewer approves publishing: (edit and replace with @githubid)
• Editorial team approved publishing: (edit and replace with @githubid)
• Add a thumbnail image for your blog if one is available
• Text nugget summarizing your article. 2-3 lines to draw the reader's attention. Possibly the opening paragraph can be used.
• Blog author team signoffs
  • AMD Employees only: Legal self review traffic lights completed: (edit and replace with @githubid)
  • Licenses file included for content is correct: (edit and replace with @githubid)
  • Changes from technical review and editorial team are acceptable: (edit and replace with @githubid)

[saadrahim]

Don't worry about the meta data. We are transitioning to a new system and don't expect external contributors to have to navigate it. An editor will correct them for you.

[saadrahim]

Thanks for the blog. I took a quick look through. Really appreciate the contribution and will work to get this out. I am off next week but will leave the additional approvals to the editorial team.

[saadrahim]

In case you are not aware, you can take a look at a preview of your blog via the github checks. Here is the link for convenience.

[amd-isparry]

Have you seen https://github.com/ROCm/ROCm/blob/develop/tools/rocm-build/ROCm.mk
This is the dependency matrix in Makefile form used by the internal CI.

[garrettbyrd]

I had not seen this, this is definitely useful for handling dependencies within the ROCm stack. I suppose the advantages that Spack brings are that 1. the verbosity of spack spec provides clarity of dependencies beyond the ROCm stack and 2. this allows one to derive ROCm dependencies for non-ROCm software, e.g. PyTorch. I have no doubt a similar graphic could be generated from the Makefile, but then connections to external packages are lost.

Regardless, I have reworded this section to better reflect why Spack is useful in this case.

[fluidnumerics-joe]

Is the ROCm.mk file something that is really digestible by a typical ROCm user to understand dependencies between ROCm packages ? While it seems like a great tool for internal CI, what about end users who are asking about how to build ROCm from source ?

[amd-isparry]

There are published instructions for building ROCm from source, in the same way that the internal CI does it. Essentially (i.e. I am skipping over some details, arguements to commands ... ) the steps are

1. repo init # Pull a manifest describing the commits which make up ROCm.
2. repo sync # Pull the actual code
3. docker run -p $PWD:/src $container make -f /src/ROCm/tools/rocm,-build/ROCm.mk -j 50 # Do the build

It is not required to use dockerr, it is just a nice way to get a controlled build environment with all needed tools installed..

This is not to say that this way is better or worse than using spack, it is just different.

[fluidnumerics-joe]

@amd-isparry - Wild. So, there's "TheRock", ROCm.mk makefile (docker-centric), and spack.

[fluidnumerics-joe]

@garrettbyrd - do we call out specifically the benefit of being able to install select packages from ROCm for specific use cases, e.g., pytorch does not require all ROCm packages.

[garrettbyrd]

@fluidnumerics-joe Yes, this line pushes that point.

... Although mivisionx comes packaged with ROCm by default, many ROCm components do not require this component. This underscores the utility of selective component installation via Spack.