Re: Running up that (HIP) hill
Hi,
On Wed, 2022-02-16 at 16:30 +0100, Maxime Chambonnet wrote:
> - imported in a MUT (vendoring other github repos) way
> gbp import-orig --component=clr --component=opencl \
> --component=hip --pristine-tar --uscan
>
TBH I very much dislike squashing multiple sources into a single one.
They aren't tightly coupled modules, right?
What's the motivation for multi source?
>
> So the package currently installs in GNUInstallDirs -
> /usr/lib/x86_64-linux-gnu, /usr/include/hip. There are two main
> shared
> objects: libamdhip64-5 and libhiprtc-builtins-5.
lgtm
> - device-side (GPU kernels), allegedly rocmgdb ioctls are not in
> the amdgpu.ko of the debian kernel yet.
The first upload of this package will enter experimental. Have you
checked the kernel (5.17) in debian/experimental?
> rocmgdb advertises "seamless debug sessions between CPU and GPU",
> so is fixing dwz even a requirement?
> - I am not sure if the shared objects will work for any other GPU
> than gfx906 currently...
>
> Basically, there is work, at least for me, to undestand what hip is
> about still: I don't understand clearly what is in the elf files and
> I would need to dive in elf spec more for dwz, for the lintian
> warning
> symbols-file-contains-current-version-with-debian-revision, and
> finally in order to look for the presence of GPU-code in there.
debian/*.symbols file should not contain lines like ".* 5.0.0-1",
where the "-1" is the debian revision. Just removing that should
eliminate that warning.
> There are also at least two packages in the hip department that would
> be nice packaging IMO: the hip-examples, and the hip-testsuite repos.
> Maybe also hipcc and hipcpu?
the testsuite sounds great as a high-level sanity checker for the
whole stack of packages in debian.
> This was me throwing all I have about this package, not knowing very
> well what to do next / knowing that $DAYJOB will be taxing here next
> weeks.
Just take your time.
Reply to: