+ notes: 'PR #2120 open (draft). No CI result yet and no local rehearsal was possible, so the build is entirely unvalidated - the first riscv64 run is what has to answer whether it fits. 3.3.1 confirmed latest on PyPI (3.4.0 exists only on paddlepaddle.org.cn/packages); wheel version comes straight from $PADDLE_VERSION, which cmake/version.cmake reads before falling back to version.txt (still 3.3.0 at the v3.3.1 tag). Not architecturally blocked, and the CUDA/xbyak reputation does not survive reading the build: WITH_GPU defaults to ${CUDA_FOUND}, WITH_MKL and WITH_AVX to ${AVX_FOUND}, WITH_ONEDNN needs AVX2, WITH_CINN/WITH_OPENVINO/WITH_DISTRIBUTE are OFF, and the three kernels/fusion/cpu/*avx* sources are removed from the source list unless AVX512F_FOUND - so on riscv64 every x86-specific component switches itself off except WITH_XBYAK, which upstream''s own WITH_ARM/WITH_SW/WITH_MIPS/WITH_LOONGARCH blocks already force OFF and route through the scalar jit/refer kernels. Upstream publishes linux_aarch64 wheels (cp39-cp313, on its own index, not PyPI) built exactly that way, so the non-x86 CPU path is real and maintained. The whole arch-gate surface is five files: cmake/flags.cmake''s unconditional -m64 and four #if blocks that select x86 intrinsics by listing the non-x86 architectures Paddle knows (phi/backends/cpu/cpu_info.{h,cc}, phi/core/platform/denormal.cc, phi/kernels/funcs/search_compute.h); everything else is already correct (phi/common/float16.h and both spin_lock.h test __x86_64__ directly). Zero ''riscv'' strings anywhere in the v3.3.1 tree, so this is entirely new territory upstream - but community members have built Paddle natively on riscv64 before and hit only ordinary problems (Paddle#61770 warnings-as-errors on 2.4.2, Paddle#62037 ''undefined symbol: __atomic_exchange_1'', i.e. missing -latomic for sub-word atomics, which patch 0001 adds up front). Real finding worth the port on its own (new gotcha 418): cmake/external/lapack.cmake downloads ONE prebuilt tarball for all of Linux, lapack_lnx_v3.10.0.20210628.tar.gz, and it is x86-64 only; setup.py then copies LAPACK_LIB/BLAS_LIB/GFORTRAN_LIB/GNU_RT_LIB_1 into paddle/libs/ unconditionally, so upstream''s released paddlepaddle-3.3.1-cp312-cp312-linux_aarch64.whl ships x86-64 liblapack.so.3, libblas.so.3, libgfortran.so.3 and libquadmath.so.0 next to a genuinely aarch64 libopenblas.so.0 (confirmed by downloading it and running file on the extracted libs). Nothing links against them - phi/backends/dynload/lapack.cc dlopens liblapack.so.3 - so the build stays green and only paddle.linalg fails at runtime. Patch 0003 builds the same Reference-LAPACK v3.10.0 from source instead, gated on WITH_RISCV, using the image''s gfortran 14.3.1. Three patches total, all verified to apply cleanly to a pristine v3.3.1 checkout: 0001 adds WITH_RISCV (mirrors the WITH_LOONGARCH block, plus -latomic, no -m64, WITH_SLEEF=OFF since Paddle only reaches SLEEF through AVX paths), 0002 adds PADDLE_WITH_RISCV to the four gates, 0003 the LAPACK source build. Workflow drives the manylinux_2_39_riscv64 container directly like build-vtk.yml (Paddle has no wheel workflow on GitHub; ci/run_setup.sh is the script its own CI drives), exports the CPU WITH_* set plus WITH_SHARED_PHI/WITH_SHARED_IR=ON to match the released wheels'' libphi_core.so/libpir.so split, then setup.py bdist_wheel + auditwheel repair; 10GB swap and timeout-minutes 2880 as build-vtk.yml needs on these 4-core runners. Matrix is cp312/cp313 only - upstream ships cp39-cp313 for 3.3.1, so there is no cp314 counterpart. gpl_sources job (packages: gcc) because setup.py copies the image''s libgfortran.so.5/libquadmath.so.0 into paddle/libs/. Runtime deps all resolve: numpy/Pillow/protobuf on pypi.riseproject.dev, safetensors riscv64 on PyPI, rest pure-Python. Test is paddle.utils.run_check() (upstream''s documented post-install check) plus a QR round-trip to exercise the new LAPACK. Main open risk is cost, not architecture: 1.3M lines of heavily templated C++ plus the third_party world, per interpreter, on 4-core riscv64 runners - VTK at comparable scale needed ~18h+ per leg against a 48h budget, and Paddle''s phi kernels are far more template-heavy, so if the first run does not fit 2880 minutes this becomes a park-as-disproportionate candidate alongside ortools/mediapipe. Secondary unknowns, all discoverable only on real hardware: OpenBLAS 0.3.28''s riscv64 auto-detect (no TARGET= passed, matching upstream), cryptopp/gloo/warpctc on riscv64, CMake 4.4.3 policy floors in third-party projects Paddle does not already pass CMAKE_POLICY_VERSION_MINIMUM=3.5 to, and the final link of libpaddle.so (193MB on aarch64) within the runner''s RAM. Worktree .claude/worktrees/agent-a77323204675e1c48, branch port/paddlepaddle.'
0 commit comments