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

Re: Question about how to handle HIP vs hipamd

Thanks for the response.

Currently my test fedora source packages that I have are:
- rocm-opencl (two sources: rocm-opencl-runtime, ROCclr)
- rocm-hip (HIP, hipamd)

The reason four sources are needed right now for HIP is because ROCclr is a build dep for hipamd and is built as a part of building hipamd. In fact, ROCclr is a build dep for both hipamd and rocm-opencl. The complication is that ROCclr and OpenCL share a lot of code. This is why building ROCclr requires the two sources (ROCclr and ROCm-OpenCL-runtime).

I'm working on a patch to separate librocclr as a subpackage of rocm-opencl, so this package can be consumed by hip as a build dep. This reduces the sources needed to build hip down to 2 (HIP and hipamd) and avoids building ROCclr twice (once during openCL, once during HIP).

Beyond that, making a "hip" (HIP) and "rocm-hip" (hipamd) separate packages seems like the next logical step, but I wanted to see of there's interest in implementing it this way.

The rational for packaging HIP separate is:
- HIP is vendor generic
- HIP does not logically depend on hipamd
- HIP seems to work similar to opencl-headers from my view, but with hipcc bits too
- separate packages allows other vendors to adopt HIP

With your slicing, we could do:
- HIP source : produces hipcc and hip-headers packages (maybe hipcc-dev?)
- hipamd source: produces lib* packages, uses hipcc/hip-headers as a builddep

Please let me know if this seems like a good path to pursue, or if you think keeping HIP and hipamd together seems better.

Thanks!

On May 13, 2022 5:20:41 p.m. EDT, "Étienne Mollier" <emollier@emlwks999.eu> wrote:
Hi Jeremy,

Jeremy Newton, on 2022-05-12:
I was speaking to some of the HIP developers to help understand why HIP and hipamd are split into two source trees.
It seems like HIP is just the common headers and scripts, while hipamd is the vendor implementation.

While HIP is not technically implemented on other vendors, I believe the design is to provide vendor agnostic headers and scripts in the HIP source tree.

Maxime could accommodate by setting up multi-upstream tarballs
in the source package under preparation on Salsa[3].  It is an
uncommon layout, and I'm not too sure it doesn't get in the way
of most packager's workflows, but I could adjust the package a
bit so it fits mine.

Interestingly, the package I have on Salsa is actually four
source code repositories glued together: hipamd and hip, but
also rocclr and rocm-opencl-runtime.  I assume it made sense to
include them in the initial packaging steps; I caught the train
in flight.

So, I'm thinking about the best way to package HIP on Fedora, and in turn help Debian packaging. My thought is to make a hip package based on the HIP source tree with two sub-packages: the "hip-utils" package with the scripts (bin directory [1]) and a "hip-headers" package with the headers (include/hip directory [2]). This was inspired by how openCL works with the opencl-headers package.

If this makes sense, then I'm going to draft up some patches to allow hipamd to build off packaged headers instead of requiring the full HIP source tree. Please let me know if you have any thoughts on this.

I had a quick lookup of the d/control file of hipamd, and at the
time of writing this, the slicing in binary packages is as
follows:

  * hipcc: contains hip utility scripts;
  * libamdhip64-5: contains libamdhip64.so.5;
  * libamdhip64-dev: contains headers;
  * libhiprtc-builtins5: contains libhiprtc-builtins.so.5.

There are also provisional definitions for libopencl (probably
too generic, the name will change), libamdocl64 and librocclr.
This is all work in progress at the moment, it's still time to
change names if need be (naming things is hard).


I am currently trying to finish the packaging of rocm-hipamd so
it could be ready for upload to New queue soon hopefully.  The
software currently builds, but the test suite has to remain
disabled for the moment: I reached a point where I hit the
symptoms described by Cory in #1010467[4] while running the test
suite.  The necessary patch[5] looks in good shape to make it to
the upcoming clang 14 thankfully; thanks Cory!

[1] hip bin directory: https://github.com/ROCm-Developer-Tools/HIP/tree/develop/bin
[2] hip include directory: https://github.com/ROCm-Developer-Tools/HIP/tree/develop/include/hip
[3]: https://salsa.debian.org/rocm-team/rocm-hipamd/
[4]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010467
[5]: https://github.com/llvm/llvm-project/issues/55341

Have a nice day,  :)
-- 
Étienne Mollier <emollier@emlwks999.eu>
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.
On air: Kaprekar's Constant - A Silent Drum
Reply to: