[Feature]: Add HIPCC_PARALLEL_JOBS environment variable to enable easier parallel build for developers/packagers.

[darix]

Suggestion Description

while working on integrating rocm/hipcc into more packages in openSUSE. I noticed that openimagedenoise spends like 45 minutes compiling all the different GPU flavors.

in one process. not multithreaded. then i learned there is the --parallel-jobs parameter.

the problem is ... to enable that we would need to patch the build system of every package. Which can be a lot of fun through all the abstraction layers.

for openSUSE we already have https://build.opensuse.org/projects/openSUSE:Factory/packages/memory-constraints/files/memory-constraints.macros?expand=1 to restrict e.g. gcc/clang based on the available memory. hipcc also seems to be about 1GB per process when running with --parallel-jobs.

to avoid having to patch each and every build system. having an environment variable to enable parallel jobs, would make the job of developers and packagers a lot easier.

Operating System

openSUSE Tumbleweed

ROCm Component

• hipcc

[e4t]

Just for clarification: What @darix was trying to say was: one needs to adjust the build system (ie cmake) control files in every software package.

[zichguan-amd]

Hi @darix and @e4t, thanks for the suggestion. We could add something like that to hipcc, but hipcc is getting deprecated soon, see https://rocm.docs.amd.com/en/docs-7.2.0/about/release-notes.html#id23. Clang doesn’t really use env vars to manage command line options, see what clang uses right now https://clang.llvm.org/docs/CommandGuide/clang.html#environment. It would help to know the build time with --parallel-jobs (you mentioned ~45 min without). Compiler team's recommendation is if there are any libraries/packages that benefits from the option then they should be updated to use --parallel-jobs.

[darix]

as a packager that means we have to patch each and every cmakefile.

another option would be that AMD Clang maybe just inherits the --jobs flag that is passed to make/ninja.

And this whole thing seems like a special case of compiling with having so many code targets in one go. That's the main reason why i thought that this should be using parallel building normally.