sci-ml/caffe2
A deep learning framework
Screenshots
-
caffe2-2.11.0-r90~amd64 ~arm64cuda cusparselt distributed fbgemm flash gloo kineto memefficient mimalloc mkl mpi nccl nnpack +numpy onednn openblas opencl openmp qnnpack rocm xnnpack python_single_target_python3_11 python_single_target_python3_12 python_single_target_python3_13 python_single_target_python3_14 +amdgpu_targets_gfx908 +amdgpu_targets_gfx90a +amdgpu_targets_gfx942 +amdgpu_targets_gfx1030 +amdgpu_targets_gfx1100 +amdgpu_targets_gfx1101 +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 amdgpu_targets_gfx1102 amdgpu_targets_gfx1103 amdgpu_targets_gfx1150 amdgpu_targets_gfx1151
View 
Download 
Browse License: BSD Overlay: stuff -
caffe2-2.11.0-r3~amd64 ~arm64cuda cusparselt distributed fbgemm flash gloo kineto memefficient mimalloc mkl mpi nccl nnpack +numpy onednn openblas opencl openmp qnnpack rocm xnnpack python_single_target_python3_11 python_single_target_python3_12 python_single_target_python3_13 python_single_target_python3_14 +amdgpu_targets_gfx908 +amdgpu_targets_gfx90a +amdgpu_targets_gfx942 +amdgpu_targets_gfx1030 +amdgpu_targets_gfx1100 +amdgpu_targets_gfx1101 +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 amdgpu_targets_gfx1102 amdgpu_targets_gfx1103 amdgpu_targets_gfx1150 amdgpu_targets_gfx1151
View Download Browse License: BSD Overlay: gentoo -
caffe2-2.10.0-r6~amd64 ~arm64cuda cusparselt distributed fbgemm flash gloo memefficient mimalloc mkl mpi nccl nnpack +numpy onednn openblas opencl openmp qnnpack rocm xnnpack python_single_target_python3_11 python_single_target_python3_12 python_single_target_python3_13 python_single_target_python3_14 +amdgpu_targets_gfx908 +amdgpu_targets_gfx90a +amdgpu_targets_gfx942 +amdgpu_targets_gfx1030 +amdgpu_targets_gfx1100 +amdgpu_targets_gfx1101 +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 amdgpu_targets_gfx1102 amdgpu_targets_gfx1103 amdgpu_targets_gfx1150 amdgpu_targets_gfx1151
View Download Browse License: BSD Overlay: gentoo
ChangeLog
commit f1e7ab9cddb007e7de2e4e4e87ffedd361b212ad
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Sat May 9 00:44:08 2026 +0200
sci-ml/caffe2: drop dead !sci-libs/QNNPACK blocker
QNNPACK has never existed as a separate Gentoo package (verified
2026-05-09 — no entry in ::gentoo's sci-libs/, no diff-filter=A hits in
::gentoo history). Upstream PyTorch vendors it and exposes the build
toggle as USE_PYTORCH_QNNPACK, which we already wire via the qnnpack
USE flag. The blocker was protecting against a separate package that
never landed. pkgcheck NonexistentBlocker.
commit f19ffa2a53036faae2f64194c8b2f7c7c15e3fb0
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Fri May 8 19:29:35 2026 +0200
sci-ml/caffe2: drop two orphan patches inherited from ::gentoo fork
Both patches target older PVs (2.6.0 / 2.10.0) that 2.11.0-r90's
PATCHES= no longer references; the array uses $- variants for the
relevant fixes (mimalloc, rocm-fix-std-cpp17). Came along when forking
from ::gentoo's -r3 to add the MKL public-link scrub.
commit 78e2fba68899c5e58faba344002934108b58e32c
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Fri May 8 01:25:42 2026 +0200
sci-ml/caffe2: fork ::gentoo's 2.11.0-r3 to -r90 with MKL public-link scrub
::gentoo's caffe2 ships caffe2/cmake/public/mkl.cmake unchanged from
upstream pytorch — calls find_package(MKL) and dumps the full result
into caffe2::mkl's INTERFACE_LINK_LIBRARIES with no filter. On hosts
with Intel oneAPI installed, the resolver is Intel's own MKLConfig.cmake
which by default returns the full HPC / Cluster Edition lib set,
including libmkl_scalapack_ilp64, libmkl_cdft_core,
libmkl_blacs_intelmpi_ilp64 (all MPI-distributed), and libmkl_intel_thread
(Intel-OpenMP threading layer). Those libs only exist when Intel's
separate Cluster + Compiler oneAPI packages are also installed; the
basic intel-oneapi-mkl package omits them.
Because they end up in caffe2::mkl's public link interface, every
downstream consumer that links against torch::torch (vllm's
cumem_allocator, custom torch C++ extensions, etc.) inherits them
and the link fails with "cannot find -lmkl_scalapack_ilp64" etc.
torch::torch's public APIs never reach BLACS / ScaLAPACK / distributed
FFT — distributed-tensor paths use NCCL / Gloo / MPI directly, not
MKL's BLACS. So filtering them is purely subtraction of incorrect
public-link-interface clutter. Forcing MKL_THREADING=gnu_thread before
the find pulls libmkl_gnu_thread (always available) instead of
libmkl_intel_thread, and pairs cleanly with system libgomp — also
avoids the multi-OpenMP-runtime mixing trap (libgomp + libiomp5 in
the same process can oversubscribe / deadlock).
Verified 2026-05-08 against caffe2-2.11.0 with USE="cuda distributed
fbgemm gloo memefficient mkl mpi nnpack numpy onednn openblas opencl
openmp": full rebuild + import torch succeed identically; downstream
consumers (vllm USE=cuda's cumem_allocator extension) link cleanly.
Upstream pytorch's cmake/public/mkl.cmake on main still has the same
unfiltered behaviour as of 2026-05-08; no upstream PR open for this
specific scrub. Drop this -r90 fork when an equivalent upstream fix
lands.
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Sat May 9 00:44:08 2026 +0200
sci-ml/caffe2: drop dead !sci-libs/QNNPACK blocker
QNNPACK has never existed as a separate Gentoo package (verified
2026-05-09 — no entry in ::gentoo's sci-libs/, no diff-filter=A hits in
::gentoo history). Upstream PyTorch vendors it and exposes the build
toggle as USE_PYTORCH_QNNPACK, which we already wire via the qnnpack
USE flag. The blocker was protecting against a separate package that
never landed. pkgcheck NonexistentBlocker.
commit f19ffa2a53036faae2f64194c8b2f7c7c15e3fb0
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Fri May 8 19:29:35 2026 +0200
sci-ml/caffe2: drop two orphan patches inherited from ::gentoo fork
Both patches target older PVs (2.6.0 / 2.10.0) that 2.11.0-r90's
PATCHES= no longer references; the array uses $- variants for the
relevant fixes (mimalloc, rocm-fix-std-cpp17). Came along when forking
from ::gentoo's -r3 to add the MKL public-link scrub.
commit 78e2fba68899c5e58faba344002934108b58e32c
Author: Ivan S. Titov <iohann.s.titov@gmail.com>
Date: Fri May 8 01:25:42 2026 +0200
sci-ml/caffe2: fork ::gentoo's 2.11.0-r3 to -r90 with MKL public-link scrub
::gentoo's caffe2 ships caffe2/cmake/public/mkl.cmake unchanged from
upstream pytorch — calls find_package(MKL) and dumps the full result
into caffe2::mkl's INTERFACE_LINK_LIBRARIES with no filter. On hosts
with Intel oneAPI installed, the resolver is Intel's own MKLConfig.cmake
which by default returns the full HPC / Cluster Edition lib set,
including libmkl_scalapack_ilp64, libmkl_cdft_core,
libmkl_blacs_intelmpi_ilp64 (all MPI-distributed), and libmkl_intel_thread
(Intel-OpenMP threading layer). Those libs only exist when Intel's
separate Cluster + Compiler oneAPI packages are also installed; the
basic intel-oneapi-mkl package omits them.
Because they end up in caffe2::mkl's public link interface, every
downstream consumer that links against torch::torch (vllm's
cumem_allocator, custom torch C++ extensions, etc.) inherits them
and the link fails with "cannot find -lmkl_scalapack_ilp64" etc.
torch::torch's public APIs never reach BLACS / ScaLAPACK / distributed
FFT — distributed-tensor paths use NCCL / Gloo / MPI directly, not
MKL's BLACS. So filtering them is purely subtraction of incorrect
public-link-interface clutter. Forcing MKL_THREADING=gnu_thread before
the find pulls libmkl_gnu_thread (always available) instead of
libmkl_intel_thread, and pairs cleanly with system libgomp — also
avoids the multi-OpenMP-runtime mixing trap (libgomp + libiomp5 in
the same process can oversubscribe / deadlock).
Verified 2026-05-08 against caffe2-2.11.0 with USE="cuda distributed
fbgemm gloo memefficient mkl mpi nnpack numpy onednn openblas opencl
openmp": full rebuild + import torch succeed identically; downstream
consumers (vllm USE=cuda's cumem_allocator extension) link cleanly.
Upstream pytorch's cmake/public/mkl.cmake on main still has the same
unfiltered behaviour as of 2026-05-08; no upstream PR open for this
specific scrub. Drop this -r90 fork when an equivalent upstream fix
lands.