sys-cluster/rocSHMEM
GPU-centric OpenSHMEM-like partitioned global address space runtime
Screenshots
-
rocSHMEM-10.0.0~amd64+ipc mpi +single-node sdma +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 2c564d0a32ef48f949d998d4f968b711c61748ea
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Mon Aug 31 10:17:08 2026 +0200
sys-cluster/rocSHMEM: new package, add 10.0.0
GPU-centric OpenSHMEM-like PGAS runtime: device code issues its own puts, gets
and collectives from inside a kernel instead of having the host marshal them
between launches. ::gentoo carries nothing of it. sys-cluster alongside the MPI
implementations it bootstraps from, rather than sci-libs -- this is a
communication runtime.
Carries one patch, for a real upstream bug rather than a Gentoo adaptation:
src/CMakeLists.txt guards the SDMA backend directory with if(USE_SDMA), so
src/sdma/anvil.cpp (which defines everything in namespace sdma_anvil) is only
compiled when that is on -- but sdma/gin_anvil_sdma_factory.cpp, which calls
into that namespace, sits in the unconditional source list. Upstream's own
default of USE_SDMA=OFF therefore fails to link with a batch of
"undefined reference to `sdma_anvil::...'". The patch moves the factory next to
the implementation it needs so both follow the same switch; it is upstreamable
as-is.
Two configure inputs are required because upstream assumes a bundled /opt/rocm:
EXPLICIT_ROCM_VERSION (its own documented escape hatch -- otherwise a
find_file(... REQUIRED) for .info/version aborts configure) and ROCM_PATH,
which is normally derived from that file's location and would otherwise end up
empty.
Upstream's DEFAULT_GPUS lists only gfx90a/gfx1100/gfx1201/gfx942 plus gfx950
and gfx1250, but a user-supplied GPU_TARGETS is honoured and validated with
rocm_check_target_ids, which tests compiler support rather than membership of
that list -- so the eclass target set is passed straight through and upstream's
own check drops anything unsupported.
Dependencies follow the built artifact: objdump -p on librocshmem.so reports
only libhsa-runtime64.so.1 and libamdhip64.so.7, and neither of its two
dlopen/dlsym relocations names another ROCm library. hsakmt and numactl are
linked only under $<BOOL:$>, so they are gated on that flag; amd_smi
is a configure-time capability probe and rocprofiler-register a QUIET lookup
that leaves no NEEDED entry, so both are DEPEND-only.
Build-verified and run-verified on gfx1150. The installed rocshmem_info reports
Compiled Arch(s) gfx1150, System Arch gfx1150, "System Arch is supported: Yes",
ROCm 10.0.0 and the IPC conduit active -- so the library is not merely built
but recognises this GPU as a supported target.
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Mon Aug 31 10:17:08 2026 +0200
sys-cluster/rocSHMEM: new package, add 10.0.0
GPU-centric OpenSHMEM-like PGAS runtime: device code issues its own puts, gets
and collectives from inside a kernel instead of having the host marshal them
between launches. ::gentoo carries nothing of it. sys-cluster alongside the MPI
implementations it bootstraps from, rather than sci-libs -- this is a
communication runtime.
Carries one patch, for a real upstream bug rather than a Gentoo adaptation:
src/CMakeLists.txt guards the SDMA backend directory with if(USE_SDMA), so
src/sdma/anvil.cpp (which defines everything in namespace sdma_anvil) is only
compiled when that is on -- but sdma/gin_anvil_sdma_factory.cpp, which calls
into that namespace, sits in the unconditional source list. Upstream's own
default of USE_SDMA=OFF therefore fails to link with a batch of
"undefined reference to `sdma_anvil::...'". The patch moves the factory next to
the implementation it needs so both follow the same switch; it is upstreamable
as-is.
Two configure inputs are required because upstream assumes a bundled /opt/rocm:
EXPLICIT_ROCM_VERSION (its own documented escape hatch -- otherwise a
find_file(... REQUIRED) for .info/version aborts configure) and ROCM_PATH,
which is normally derived from that file's location and would otherwise end up
empty.
Upstream's DEFAULT_GPUS lists only gfx90a/gfx1100/gfx1201/gfx942 plus gfx950
and gfx1250, but a user-supplied GPU_TARGETS is honoured and validated with
rocm_check_target_ids, which tests compiler support rather than membership of
that list -- so the eclass target set is passed straight through and upstream's
own check drops anything unsupported.
Dependencies follow the built artifact: objdump -p on librocshmem.so reports
only libhsa-runtime64.so.1 and libamdhip64.so.7, and neither of its two
dlopen/dlsym relocations names another ROCm library. hsakmt and numactl are
linked only under $<BOOL:$>, so they are gated on that flag; amd_smi
is a configure-time capability probe and rocprofiler-register a QUIET lookup
that leaves no NEEDED entry, so both are DEPEND-only.
Build-verified and run-verified on gfx1150. The installed rocshmem_info reports
Compiled Arch(s) gfx1150, System Arch gfx1150, "System Arch is supported: Yes",
ROCm 10.0.0 and the IPC conduit active -- so the library is not merely built
but recognises this GPU as a supported target.