Re: Packaging hipblaslt in progress
On Sun, Mar 10, 2024 at 10:26:28PM -0600, Cordell Bloor wrote:
> Hi Kari,
>
> On 2024-03-10 06:19, Kari Pahula wrote:
> > I've been working on getting hipblaslt packaged (ITP #1064071). The
> > status right now is that it compiles and I have been trying to get the
> > tests run before seeing to the rest of the packaging flow. I tried to
> > jump to 6.0.2 first but ROCm 5.7 wasn't quite ready for it so I stuck
> > to 5.7 for now.
>
> Interesting. It relies on functionality from ROCm 6?
################################################################################
# Tensile Create Library
Tensile::WARNING: Did not detect SupportedISA: [(8, 0, 3), (9, 0, 0), (9, 0, 6), (9, 0, 8), (9, 0, 10), (9, 4, 0), (9, 4, 1), (9, 4, 2), (10, 1, 0), (10, 1, 1), (10, 1, 2), (10, 3, 0), (11, 0, 0), (11, 0, 1), (11
, 0, 2)]; cannot benchmark assembly kernels.
make[3]: Leaving directory '/home/kaol/deb/hipblaslt/6/hipblaslt/obj-x86_64-linux-gnu'
[ 11%] Built target hipblaslt-test-data
/home/kaol/deb/hipblaslt/6/hipblaslt/obj-x86_64-linux-gnu/library/build_tmp/ops/S_8_32_gfx803.s:257:1: error: directive requires gfx90a+
.amdhsa_accum_offset 8
^~~~~~~~~~~~~~~~~~~~
/home/kaol/deb/hipblaslt/6/hipblaslt/obj-x86_64-linux-gnu/library/build_tmp/ops/S_8_32_gfx803.s:258:1: error: unknown directive
.amdhsa_next_free_vgpr .amdgcn.next_free_vgpr
^
/home/kaol/deb/hipblaslt/6/hipblaslt/obj-x86_64-linux-gnu/library/build_tmp/ops/S_8_32_gfx803.s:259:1: error: unknown directive
.amdhsa_next_free_sgpr .amdgcn.next_free_sgpr
^
/home/kaol/deb/hipblaslt/6/hipblaslt/obj-x86_64-linux-gnu/library/build_tmp/ops/S_8_32_gfx803.s:260:1: error: unknown directive
.end_amdhsa_kernel
^
And more like that. Later on:
clang++-17: error: no such file or directory: '/home/kaol/deb/hipblaslt/6/hipblaslt/obj-x86_64-linux-gnu/library/build_tmp/ops/S_8_32_gfx803.o'
It didn't seem like a fruitful approach to try to continue from that.
> > Could someone who's more familiar with this have a look? Looking at
> > radeontop it looks like the GPU is doing something at least when I run
> > the program.
>
> I'll take a look later this week, unless someone beats me to it.
I've been busy with some other things but I've been looking at this
more today. I tried "export HSA_OVERRIDE_GFX_VERSION=10.3.0" that you
suggested in your second message but I got all the same test errors
with that. Even after just removing my compatibility patch and only
using the environment variable.
I'm afraid I'm stumped with this. I've tried looking at how rocblas
does this but I'm coming up short with what else to try. I can finish
with other packaging work but it won't do to upload this if I haven't
checked that it's functioning properly.
> > As a second matter, are any of the data files in the included Tensile
> > DFSG burdened? I've done a dfsg repack for my source package but that
> > only removed docs/cleanup_text.sh since a file with just "By Lee
> > Killough" comment looked suspicious to me and it's not used for the
> > build. But rocblas has the same file so it may be fine. But I think
> > the included yaml files do need some reviewing, I see that rocblas
> > removes some due to DFSG violations and I don't think I can tell from
> > the ones included with hipblaslt if they also need to be removed or
> > replaced.
>
> Lee Killough was an AMD employee on the rocBLAS team. AMD owns the copyright
> to all his contributions to the ROCm libraries. The root license file should
> apply, but feel free to file an issue asking for clarification. There should
> probably be a standard copyright header in every code file.
I think this is all the clarification needed about the file. If an
FTP master asks I can point to this discussion say that an AMD
employee said it's fine.
> With regards to DFSG issues in the Tensile sources, there were a few kernels
> that were provided as binary blobs. For those, the problem was that the
> shader language used for the original sources did not have an open source
> compiler, so the compiled sources were checked in instead. The YAML files
> that were removed from rocBLAS were those that referenced the removed
> shaders. I believe that the binary blobs were removed in ROCm 6, so Tensile
> should no longer be DFSG burdened. However, I have not actually reviewed the
> updates yet myself.
I'm not quite sure that's actually a DFSG issue. I think it's enough
to just have the source available with an acceptable license. Though
it's not ideal for sure. I think there was a case about a game's
music getting a pass despite the program to generate the music being
proprietary.
> > I'm guessing it could be a future project to package
> > https://github.com/ROCm/Tensile and use that for both rocblas and
> > hipblaslt. Buildd maintainers would like it at least, running Tensile
> > during a build seems to be quite a room warmer.
>
> I've filed an ITP for rocm-tensile [1]. However, the separate Tensile
> package will not have any significant effect on build times.
I suspected that to be the case. But I agree with what you said,
using single dependency for rocblas and hipblaslt is good practice.
Reply to: