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

Re: Question about how to handle HIP vs hipamd



Hi Jeremy,

Jeremy Newton, on 2022-05-13:
> 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.

I was a bit confused by your initial proposal, but now that you
reworded it, it makes more sense to me.  Thanks for having taken
the time to clarify it.  Yes this is probably a good path to
pursue, it seems to me.

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.

Attachment: signature.asc
Description: PGP signature


Reply to: