Re: Question about how to handle HIP vs hipamd

[Jeremy Newton <alexjnewt@fastmail.com>]

Hi Cory,

A quick correction...

The tentative proposal from the OpenCL/HIP team is to place hipamd, ROCclr, and ROCm-OpenCL in one repo, while HIP would still be separate. This is because it matches how they test and stage code during development (all three repositories are staged/branched/released in tandem).

As a follow up proposal to them, I put in the request to make HIP a separate cmake project, as it's just a set of headers and scripts that are installed as-is within hipamd's cmake logic. To me it seems logical in the long run to separate HIP as it's own project since I believe the intention is to keep it for non vendor specific code (e.g. similar to "opencl-headers" package). I don't think that this request is a blocker for packaging, but it would simplify things.

As well, an implication of this proposal might be that rocm-opencl and hipamd would become sub packages of the same source package.

Although to double stress what you already said, this approach is not committed yet and is still gathering feedback.

Thanks

On May 26, 2022 12:53:54 a.m. EDT, Cordell Bloor <cgmb-deb@slerp.xyz> wrote:

Hello,

Jeremy and I met with the HIP development team and we discussed a number of options for simplifying the hipamd build process. I think everyone is on the same page that the status quo is less than ideal, though there was some disagreement as to the best path forward.

The preference of the HIP team is to join ROCclr, ROCm-OpenCL-Runtime, hipamd and HIP into a single repo. They do not want to maintain a stable ROCclr interface and argue that it is an implementation detail of the AMD HIP and OpenCL runtimes. It is not designed for use outside those components. While this was not the first choice of solution for Jeremy or myself, I strongly believe that development teams should have the right to choose the manner in which they work, as long as they fulfill the needs of their users.

The question, therefore, is whether this solution _is_ acceptable to users. I would imagine that the proposed runtime monorepo would be acceptable to Debian, given that it would leave the rocm-hipamd repo [1] largely unchanged in structure. The most significant difference would be that it would no longer be a multi-upstream tarball source—there would be a single upstream tarball rather than four.

I don't think anything is going to happen very quickly on this front, but please do let me know if you have any concerns.There have been no hard decisions made yet and we're still collecting feedback from various stakeholders.

Sincerely,
Cory Bloor

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