sys-libs/hipFile
Direct-to-GPU storage I/O for the ROCm platform (AMD Infinity Storage)
Screenshots
-
hipFile-10.0.0~amd64examples tools +amdgpu_targets_gfx908 +amdgpu_targets_gfx90a +amdgpu_targets_gfx942 +amdgpu_targets_gfx950 +amdgpu_targets_gfx1030 +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_gfx803 amdgpu_targets_gfx900 amdgpu_targets_gfx906 amdgpu_targets_gfx940 amdgpu_targets_gfx941 amdgpu_targets_gfx1010 amdgpu_targets_gfx1011 amdgpu_targets_gfx1012 amdgpu_targets_gfx1031
View 
Download 
Browse License: MIT Overlay: stuff
ChangeLog
commit bc888fc78e776b7c80f03d2707288e7469fc0678
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Mon Aug 31 10:06:22 2026 +0200
sys-libs/hipFile: new package, add 10.0.0
AMD's Infinity Storage library -- the ROCm counterpart to NVIDIA's GPUDirect
Storage. File data is DMA'd straight into GPU memory instead of being staged
through a host bounce buffer, with sync, async and batch entry points and a
transparent POSIX fallback. ::gentoo carries nothing of it. sys-libs rather
than sci-libs: this is storage I/O plumbing, not a math library.
Three things the build needs that are not obvious from the CMake alone:
- CMAKE_HIP_ARCHITECTURES, not GPU_TARGETS. hipFile uses CMake's FIRST-CLASS
HIP language (project(... LANGUAGES C CXX HIP)) rather than the hip::device
INTERFACE target, so the usual knob does nothing here. It compiles real
device code (src/amd_detail/backend/memcpy-kernel.hip), so an unset
architecture would silently yield kernels that cannot run on the host GPU.
src_install asserts the built code objects, same guard as media-libs/rocJPEG.
- ROCM_VERSION and ROCM_PATH. Upstream derives the version by reading
$/.info/version, a file only a bundled /opt/rocm install has;
without it CMake dies in AISInstall.cmake with "ROCM_VERSION='' does not
match the expected MAJOR.MINOR[.PATCH] form". Pointing ROCM_PATH at the
real prefix is safe -- its only other use, forcing CMAKE_INSTALL_PREFIX, is
guarded by CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT.
- sys-apps/util-linux. objdump -p on libhipfile.so.0.4.0 reports
libmount.so.1, pulled in to inspect mount points (hipFile has to work out
whether a file's filesystem supports the direct path). It is named nowhere
in upstream's CMake, so reading the build files alone would have missed it.
Conversely dev-libs/rocr-runtime is find_package(... REQUIRED) at configure
time but never appears as NEEDED, so it is DEPEND-only.
The direct path has host requirements this ebuild cannot satisfy, both
documented upstream and both recorded in the ebuild: CONFIG_PCI_P2PDMA (now
checked via linux-info, non-fatally) and a filesystem sitting directly on the
device partition -- LVM/device-mapper, dm-crypt, MD RAID, multipath and
loopback all force the POSIX fallback.
Build-verified and merged on haarmek, with gfx1150 device code confirmed
present. Run-verified as far as this host allows: hipFileDriverOpen,
hipFileHandleRegister (with O_DIRECT) and hipFileBufRegister all succeed, so
the library loads and its API works against the installed headers. Only
hipFileRead fails, which is expected here -- no P2PDMA in the kernel and both
filesystems on LVM. It returns -999 though, a value mapping to no
hipFileOpError_t at all, rather than hipFileIONotSupported or a transparent
fallback; that looks like an upstream bug and is worth re-testing on a bump.
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Mon Aug 31 10:06:22 2026 +0200
sys-libs/hipFile: new package, add 10.0.0
AMD's Infinity Storage library -- the ROCm counterpart to NVIDIA's GPUDirect
Storage. File data is DMA'd straight into GPU memory instead of being staged
through a host bounce buffer, with sync, async and batch entry points and a
transparent POSIX fallback. ::gentoo carries nothing of it. sys-libs rather
than sci-libs: this is storage I/O plumbing, not a math library.
Three things the build needs that are not obvious from the CMake alone:
- CMAKE_HIP_ARCHITECTURES, not GPU_TARGETS. hipFile uses CMake's FIRST-CLASS
HIP language (project(... LANGUAGES C CXX HIP)) rather than the hip::device
INTERFACE target, so the usual knob does nothing here. It compiles real
device code (src/amd_detail/backend/memcpy-kernel.hip), so an unset
architecture would silently yield kernels that cannot run on the host GPU.
src_install asserts the built code objects, same guard as media-libs/rocJPEG.
- ROCM_VERSION and ROCM_PATH. Upstream derives the version by reading
$/.info/version, a file only a bundled /opt/rocm install has;
without it CMake dies in AISInstall.cmake with "ROCM_VERSION='' does not
match the expected MAJOR.MINOR[.PATCH] form". Pointing ROCM_PATH at the
real prefix is safe -- its only other use, forcing CMAKE_INSTALL_PREFIX, is
guarded by CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT.
- sys-apps/util-linux. objdump -p on libhipfile.so.0.4.0 reports
libmount.so.1, pulled in to inspect mount points (hipFile has to work out
whether a file's filesystem supports the direct path). It is named nowhere
in upstream's CMake, so reading the build files alone would have missed it.
Conversely dev-libs/rocr-runtime is find_package(... REQUIRED) at configure
time but never appears as NEEDED, so it is DEPEND-only.
The direct path has host requirements this ebuild cannot satisfy, both
documented upstream and both recorded in the ebuild: CONFIG_PCI_P2PDMA (now
checked via linux-info, non-fatally) and a filesystem sitting directly on the
device partition -- LVM/device-mapper, dm-crypt, MD RAID, multipath and
loopback all force the POSIX fallback.
Build-verified and merged on haarmek, with gfx1150 device code confirmed
present. Run-verified as far as this host allows: hipFileDriverOpen,
hipFileHandleRegister (with O_DIRECT) and hipFileBufRegister all succeed, so
the library loads and its API works against the installed headers. Only
hipFileRead fails, which is expected here -- no P2PDMA in the kernel and both
filesystems on LVM. It returns -999 though, a value mapping to no
hipFileOpError_t at all, rather than hipFileIONotSupported or a transparent
fallback; that looks like an upstream bug and is worth re-testing on a bump.