Intake queue: projects screened and awaiting a fork-or-decline decision

[jeffdaily]

5 project(s) screened and waiting. Each row is a recommendation; reply in one comment saying what you want, e.g. "accept all but X and Y -- X because ..., Y because ...". Rows marked on hold are asking something else and are listed under Held back below.

#	project	licence	duplicate effort	viable	recommend
1	FlexGEMM	MIT (t1)	Upstream itself: JeffreyXiang/FlexGEMM#18 'Add AMD ROCm/HIP support' merged 2026-04-20; ATLAS-0321/FlexGEMM-rocm is a never-upstreamed duplicated kernels/hip tree, superseded. No AMD-Ecosystem or ROCm org repo.	no	decline (already-supported)
2	nvdiffrec	LicenseRef-NVIDIA-Source-Code-License (t4)	none -- no AMD/ROCm fork, no port PR or branch, no AMD mention in docs	no	decline (license-blocked)
3	DynOSAM	BSD-3-Clause (t1)	none -- no AMD-Ecosystem/ROCm repo, all 33 upstream forks vanilla, no AMD mention in upstream docs	yes	fork
4	TRELLIS.2	MIT (t1)	microsoft/TRELLIS.2#155 [ROCm] Add AMD GPU support, open non-draft since 2026-04-27, zero maintainer response; companion JeffreyXiang/CuMesh#31 closed by its own author after MOAT's CuMesh#36 opened. Coordinate, do not compete.	yes	fork
5	cuda_voxelizer	MIT (t1)	none	yes	on hold

• FlexGEMM -- Triton-based sparse-conv GEMM backend, not CUTLASS: upstream already runs on ROCm (PR Make a synced worktree the only kind, and refuse a write the trunk would reject #18 merged 2026-04-20, BUILD_TARGET=rocm in setup.py, MI300X Triton MFMA configs since the first commit, ~18.5k MI300X autotune entries shipped) so there is no port left to write; also unblocks TRELLIS.2 as a satisfied dependency.
  • full write-up: projects/FlexGEMM/notes.md
• nvdiffrec -- Inverse rendering (mesh+material+lighting from images); wholly under the NVIDIA Source Code License, non-commercial research-only (tier 4), and hard-depends on nvdiffrast which MOAT already skipped license-blocked.
  • full write-up: projects/nvdiffrec/notes.md
• DynOSAM -- ROS2 dynamic-object SLAM (BSD-3, 327 stars, active): its GPU-critical half is cv::cuda PyrLK/GoodFeatures, already ported and validated by our own opencv_contrib on gfx1100, and its own CUDA is one 327-line .cu; what decides it is whether we accept reimplementing its raw-TensorRT YOLOv8 inference on MIGraphX (no ONNX Runtime layer exists) inside a ROS2 + GTSAM + from-source-OpenCV stack.
  • full write-up: projects/DynOSAM/notes.md
• TRELLIS.2 -- Microsoft's 4B image-to-3D flagship (10.9k stars); MIT tier-1, only ~1350 lines of vendored o-voxel .cu with no warp intrinsics or cub/thrust, and setup.sh already branches on ROCm -- but an open non-draft ROCm PR #155 (andyluo7, 4 months stale, its CuMesh half closed in MOAT's favour) covers the same files, and licence-blocked nvdiffrast gates textured .glb export.
  • full write-up: projects/TRELLIS.2/notes.md
• cuda_voxelizer -- Small, actively-maintained MIT CUDA mesh voxelizer with a real GPU kernel path and no existing AMD/ROCm port; two vendored NVIDIA CUDA-Samples helper headers (helper_cuda.h, helper_string.h) carry old restrictive EULA-style text and should be reviewed/replaced during the port even though the project's own code is clean MIT.
  • full write-up: projects/cuda_voxelizer/notes.md

Held back

Flagged with triage.py verify because something needs settling before fork-or-decline is even the right question. They are in the table above and they do need an answer -- just an answer to what is written here. Clearing the flag (triage.py unskip <owner/repo>) returns one to an ordinary row.

• Forceflow/cuda_voxelizer -- vendored NVIDIA CUDA-Samples headers under the old EULA notice; admin deciding whether forking is acceptable

---

This table is a snapshot. It is regenerated in place only while nobody has answered; once a decision is recorded this issue closes and anything still undecided returns as a new one, so a reply always refers to the table above it.