sci-libs/hipTensor
High-performance tensor contraction, reduction and permutation library
Screenshots
-
hipTensor-10.0.0~amd64+amdgpu_targets_gfx908 +amdgpu_targets_gfx90a +amdgpu_targets_gfx942 +amdgpu_targets_gfx950 +amdgpu_targets_gfx1100 +amdgpu_targets_gfx1101 +amdgpu_targets_gfx1102 +amdgpu_targets_gfx1103 +amdgpu_targets_gfx1150 +amdgpu_targets_gfx1151 +amdgpu_targets_gfx1152 +amdgpu_targets_gfx1153 +amdgpu_targets_gfx1200 +amdgpu_targets_gfx1201 +amdgpu_targets_gfx1250 test
View 
Download 
Browse License: MIT Overlay: stuff
ChangeLog
commit 510f499efee0df8a27fa03cb2e9a673c744238d5
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Mon Aug 31 03:38:03 2026 +0200
sci-libs/hipTensor: new package, add 10.0.0
AMD's answer to cuTENSOR: einsum-style contraction, reduction and permutation
of arbitrary-rank tensors, implemented over Composable Kernel's kernel
instances. ::gentoo carries nothing of it.
Requires sci-libs/composable-kernel[hiptensor], which is a hard configure-time
requirement rather than a preference -- upstream's find_package asks for three
CK COMPONENTS that a default (MIOpen-narrowed) CK build does not produce.
That dependency is DEPEND-only, and that was determined from the artifact
rather than assumed. hipTensor compiles its OWN contraction instances out of
CK's header-only templates -- the link line is ~300 MB of
device_contraction_*_instance.cpp.o -- so nothing of CK survives into the
shared object: libhiptensor.so.0.1 has NEEDED libamdhip64.so.7 and nothing else
from ROCm, carries no libdevice_*/composable_kernel strings, has zero
dlopen/dlsym relocations, and the installed hiptensor-config.cmake
find_dependency()s only hip.
src_install asserts HIPTENSOR_DISABLE_DEVICE=OFF in the cache. hipTensor has a
stub mode it enables ITSELF when its target list resolves empty, emitting a
host-only library that implements the entire public API and returns
HIPTENSOR_STATUS_NOT_SUPPORTED from every entry point -- same filename, same
soname, successful build.
Recorded in the ebuild and stated plainly here: this package is NOT usable on
RDNA at ROCm 10.0. It builds, installs and initialises on gfx1150, but
hiptensorCreateContraction returns HIPTENSOR_STATUS_ARCH_MISMATCH, because all
160 contraction instance sources are `_xdl_` CDNA matrix-core kernels with not
one `_wmma_` or `_dl_` among them. Upstream's own DEFAULT_ARCHITECTURES agrees
-- gfx908/gfx90a/gfx942/gfx950 plus two generic pseudo-targets. The RDNA
amdgpu_targets_* flags are kept because they mirror upstream's
SUPPORTED_ARCHITECTURES and the package is genuinely functional on CDNA;
WMMA instances appearing upstream is what to watch for on a bump.
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Mon Aug 31 03:38:03 2026 +0200
sci-libs/hipTensor: new package, add 10.0.0
AMD's answer to cuTENSOR: einsum-style contraction, reduction and permutation
of arbitrary-rank tensors, implemented over Composable Kernel's kernel
instances. ::gentoo carries nothing of it.
Requires sci-libs/composable-kernel[hiptensor], which is a hard configure-time
requirement rather than a preference -- upstream's find_package asks for three
CK COMPONENTS that a default (MIOpen-narrowed) CK build does not produce.
That dependency is DEPEND-only, and that was determined from the artifact
rather than assumed. hipTensor compiles its OWN contraction instances out of
CK's header-only templates -- the link line is ~300 MB of
device_contraction_*_instance.cpp.o -- so nothing of CK survives into the
shared object: libhiptensor.so.0.1 has NEEDED libamdhip64.so.7 and nothing else
from ROCm, carries no libdevice_*/composable_kernel strings, has zero
dlopen/dlsym relocations, and the installed hiptensor-config.cmake
find_dependency()s only hip.
src_install asserts HIPTENSOR_DISABLE_DEVICE=OFF in the cache. hipTensor has a
stub mode it enables ITSELF when its target list resolves empty, emitting a
host-only library that implements the entire public API and returns
HIPTENSOR_STATUS_NOT_SUPPORTED from every entry point -- same filename, same
soname, successful build.
Recorded in the ebuild and stated plainly here: this package is NOT usable on
RDNA at ROCm 10.0. It builds, installs and initialises on gfx1150, but
hiptensorCreateContraction returns HIPTENSOR_STATUS_ARCH_MISMATCH, because all
160 contraction instance sources are `_xdl_` CDNA matrix-core kernels with not
one `_wmma_` or `_dl_` among them. Upstream's own DEFAULT_ARCHITECTURES agrees
-- gfx908/gfx90a/gfx942/gfx950 plus two generic pseudo-targets. The RDNA
amdgpu_targets_* flags are kept because they mirror upstream's
SUPPORTED_ARCHITECTURES and the package is genuinely functional on CDNA;
WMMA instances appearing upstream is what to watch for on a bump.